Opened 8 months ago

Last modified 13 days ago

#68017 assigned defect

gtk3 fails on 10.6 i386 32bit missing symbol _macroman2ucs

Reported by: rmottola (Riccardo) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: i386 snowleopard Cc: cooljeanius (Eric Gallager)
Port: gtk3

Description (last modified by ryandesign (Ryan Carsten Schmidt))

While compiling on 10.6 i386 32bit with all patches applied (shared on #67408) it fails to link. On 64bit I have no issues.

FAILED: gdk/libgdk-3.0.dylib 
/opt/local/bin/clang-mp-11 -arch i386  -o gdk/libgdk-3.0.dylib gdk/libgdk-3.0.dylib.p/meson-generated_.._gdkenumtypes.c.o gdk/libgdk-3.0.dylib.p/meson-generated_.._gdkmarshalers.c.o gdk/libgdk-3.0.dylib.p/meson-generated_.._gdkresources.c.o gdk/libgdk-3.0.dylib.p/gdk-private.c.o gdk/libgdk-3.0.dylib.p/gdk.c.o gdk/libgdk-3.0.dylib.p/gdkapplaunchcontext.c.o gdk/libgdk-3.0.dylib.p/gdkcairo.c.o gdk/libgdk-3.0.dylib.p/gdkcursor.c.o gdk/libgdk-3.0.dylib.p/gdkdeprecated.c.o gdk/libgdk-3.0.dylib.p/gdkdevice.c.o gdk/libgdk-3.0.dylib.p/gdkdevicemanager.c.o gdk/libgdk-3.0.dylib.p/gdkdevicepad.c.o gdk/libgdk-3.0.dylib.p/gdkdisplay.c.o gdk/libgdk-3.0.dylib.p/gdkdisplaymanager.c.o gdk/libgdk-3.0.dylib.p/gdkdnd.c.o gdk/libgdk-3.0.dylib.p/gdkevents.c.o gdk/libgdk-3.0.dylib.p/gdkframetimings.c.o gdk/libgdk-3.0.dylib.p/gdkgl.c.o gdk/libgdk-3.0.dylib.p/gdkglcontext.c.o gdk/libgdk-3.0.dylib.p/gdkglobals.c.o gdk/libgdk-3.0.dylib.p/gdkkeys.c.o gdk/libgdk-3.0.dylib.p/gdkkeyuni.c.o gdk/libgdk-3.0.dylib.p/gdkoffscreenwindow.c.o gdk/libgdk-3.0.dylib.p/gdkframeclock.c.o gdk/libgdk-3.0.dylib.p/gdkframeclockidle.c.o gdk/libgdk-3.0.dylib.p/gdkpango.c.o gdk/libgdk-3.0.dylib.p/gdkpixbuf-drawable.c.o gdk/libgdk-3.0.dylib.p/gdkprofiler.c.o gdk/libgdk-3.0.dylib.p/gdkproperty.c.o gdk/libgdk-3.0.dylib.p/gdkrectangle.c.o gdk/libgdk-3.0.dylib.p/gdkrgba.c.o gdk/libgdk-3.0.dylib.p/gdkscreen.c.o gdk/libgdk-3.0.dylib.p/gdkselection.c.o gdk/libgdk-3.0.dylib.p/gdkvisual.c.o gdk/libgdk-3.0.dylib.p/gdkwindow.c.o gdk/libgdk-3.0.dylib.p/gdkwindowimpl.c.o gdk/libgdk-3.0.dylib.p/gdkseat.c.o gdk/libgdk-3.0.dylib.p/gdkseatdefault.c.o gdk/libgdk-3.0.dylib.p/gdkdevicetool.c.o gdk/libgdk-3.0.dylib.p/gdkdrawingcontext.c.o gdk/libgdk-3.0.dylib.p/gdkmonitor.c.o gdk/libgdk-3.0.dylib.p/deprecated_gdkcolor.c.o -L/opt/local/lib -I/opt/local/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -shared -install_name @rpath/libgdk-3.0.dylib -compatibility_version 2407 -current_version 2407.32.0 -Wl,-force_load gdk/quartz/libgdk-quartz.a -Wl,-headerpad_max_install_names -lMacportsLegacySupport -arch i386 -pipe -Os -fstrict-aliasing -arch i386 -DX_LOCALE -Wl,-rpath,/opt/local/lib -lm /opt/local/lib/libgdk_pixbuf-2.0.dylib /opt/local/lib/libgobject-2.0.dylib /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libcairo.dylib /opt/local/lib/libpango-1.0.dylib /opt/local/lib/libharfbuzz.dylib /opt/local/lib/libfribidi.dylib /opt/local/lib/libcairo-gobject.dylib /opt/local/lib/libepoxy.dylib /opt/local/lib/libgio-2.0.dylib /opt/local/lib/libpangocairo-1.0.dylib -framework AppKit -framework Cocoa -framework Carbon -framework QuartzCore -framework IOSurface -framework AppKit -framework Cocoa -framework Carbon -framework QuartzCore -framework IOSurface
Undefined symbols for architecture i386:
  "_macroman2ucs", referenced from:
      _update_keymap in libgdk-quartz.a(gdkkeys-quartz.c.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Attachments (1)

gtk3_gdkkeys.patch (3.9 KB) - added by rmottola (Riccardo) 7 months ago.
remove 32bit codepath broken on 10.6

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 months ago by kencu (Ken)

it looks like you are building +quartz, which is always a bit more dodgy than +x11, especially on older systems.

Xquartz used to provide an implementation of this function for i386 here, since removed in this commit when i386 support was stripped out of Xquartz I note:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=59f22341a8b4cd468d6f37fb17dd7fde347e430b&utm_source=anzwix

comment:2 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

Weird that there couldn't be an architecture-independent implementation of this...

comment:3 Changed 8 months ago by kencu (Ken)

way back here:

https://lists.macosforge.org/pipermail/xquartz-changes/2015-June/002159.html

Jeremy bracketed that function with guards to prevent unused-function warnings.

It looks like that function is only called on 32bit builds, and I guess the linker can't find an invocation of it any longer.

https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/quartz/gdkkeys-quartz.c#L266

Probably have to inline an implemenation of the function into gdk/quartz/gdkkeys-quartz.c, also guarded by #ifdef __LP64__

comment:4 in reply to:  1 Changed 8 months ago by rmottola (Riccardo)

Replying to kencu:

it looks like you are building +quartz, which is always a bit more dodgy than +x11, especially on older systems.

Xquartz used to provide an implementation of this function for i386 here, since removed in this commit when i386 support was stripped out of Xquartz I note:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=59f22341a8b4cd468d6f37fb17dd7fde347e430b&utm_source=anzwix

Yes you are right, +quartz, I forgot to mention and i386. I wonder why that function is used only on 32bit builds, makes no sense at a first glance, it doesn't look like something architecture specific.

Changed 7 months ago by rmottola (Riccardo)

Attachment: gtk3_gdkkeys.patch added

remove 32bit codepath broken on 10.6

comment:5 Changed 7 months ago by rmottola (Riccardo)

After studying the code and comments, I think that the code using the unavailable functions can be removed. There is clearly stating that it is left in for not loosing certain keymaps in 32bit. Probably this was true for 10.5, but on 10.6 they are always missing, so I'd use the fallback code always. Probably nobody cared much since after 10.6 everything s 64bit anyway. So I attach this patch which allowed 10.6 32bit to compile and behave like 64bit. I have a working emacs on 10.6 32bit now, which is a good proof.

Would you conditionally apply it for 10.6 or later? I wonder if we should just always apply it and simplify things.

PS: emacs has some issues with Italian keyboard, but since I have them also on 64bit systems, I would not say it is caused by this patch or in any case, a solution needs to be found. I'd like to see ho things are on 10.5 where I could compare behavior, but I am unable to build emacs and all its dependencies there at the moment.

Last edited 7 months ago by rmottola (Riccardo) (previous) (diff)

comment:6 Changed 5 months ago by rmottola (Riccardo)

do you like my patch/proposal, @kencu? seems it proved itelf in practice. At least, emacs works fine. Unable yet to completely other apps to build and get usable.

comment:7 Changed 2 weeks ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:8 Changed 13 days ago by mascguy (Christopher Nielsen)

Cc: mascguy removed
Owner: set to mascguy
Status: newassigned
Note: See TracTickets for help on using tickets.