Opened 12 years ago
Closed 10 years ago
#38891 closed defect (wontfix)
Leopard PPC: webkit-gtk @2.0.1: configure fails to find glib2: absolute address to symbol _glib_micro_version in a different linkage unit not supported in _main
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.3 |
Keywords: | powerpc leopard | Cc: | sasoph@…, dershow, cooljeanius (Eric Gallager), fra.sa@… |
Port: | webkit-gtk |
Description
Trying to configure webkit-gtk @2.0.1 on Leopard ppc fails with this message:
:info:configure checking for GLIB - version >= 2.36.0... no :info:configure *** Could not run GLIB test program, checking why... :info:configure *** The test program failed to compile or link. See the file config.log for the :info:configure *** exact error that occured. This usually means GLIB is incorrectly installed. :info:configure configure: error: You need the GLib dev tools in your path
Certainly the correct version of glib2 is already installed.
The config.log reveals the real problem, though I don't understand it or know what to do about it:
configure:17118: checking for GLIB - version >= 2.36.0 configure:17233: /Volumes/Data/macports/leopard/bin/clang-mp-3.2 -o conftest -pipe -Os -arch ppc -D_REENTRANT -I/Volumes/Data/macports/leopard/include/glib-2.0 -I/Volumes/Data/macports/leopard/lib/glib-2.0/include -I/Volumes/Data/macports/leopard/include -DGTEST_USE_OWN_TR1_TUPLE=1 -D__MAC_OS_X_VERSION_MAX_ALLOWED=1050 -L/Volumes/Data/macports/leopard/lib -arch ppc conftest.c -L/Volumes/Data/macports/leopard/lib -lgmodule-2.0 -lgthread-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl >&5 ld: absolute address to symbol _glib_micro_version in a different linkage unit not supported in _main from /tmp/conftest-kPCwIl.o collect2: ld returned 1 exit status clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) configure:17233: $? = 1 configure: program exited with status 1
It was previously reported in comment:ticket:38006:6.
Attachments (3)
Change History (11)
Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | config.log added |
---|
comment:1 Changed 11 years ago by dershow
Cc: | dersh@… added |
---|
comment:3 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Summary: | webkit-gtk @2.0.1: configure fails to find glib2: absolute address to symbol _glib_micro_version in a different linkage unit not supported in _main → Leopard PPC: webkit-gtk @2.0.1: configure fails to find glib2: absolute address to symbol _glib_micro_version in a different linkage unit not supported in _main |
---|
comment:4 Changed 11 years ago by fra.sa@…
hi!same problem here in trying to install seahorse. the installation fails while installing the dependency webkit-gtk with the same error here reported in the above log. I then tried to change compiler and I used gcc 4.8. This time I passed the configure phase but then the building phase fails with the error "The MacroAssembler is not supported on this platform."
Changed 11 years ago by fra.sa@…
Attachment: | gcc4.8-main.log added |
---|
comment:6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign@…:
ld: absolute address to symbol _glib_micro_version in a different linkage unit not supported in _main from /tmp/conftest-kPCwIl.o
This same type of error is happening for boost too, also on Leopard PowerPC; see #39870. boost also uses clang on that system. Why is clang having this complaint, and only on PowerPC?
comment:7 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Excluding these two MacPorts tickets, there's only one occurrence of this type of error in all of Google: this file in someone's game which has this comment:
// fix for "ld: absolute address to symbol _NSApp in a different linkage unit not supported" // (OS X 10.6) when building for PPC
This comment was added in this revision. The problem in their case was with the symbol _NSApp
; they were using NSApp
throughout their app, and their fix was to declare a static variable nsapp
and assign [NSApplication sharedApplication]
to it and use that variable everywhere. I don't know if or how this solution applies to the issues we're seeing in webkit-gtk and boost but it's the only lead I can find.
comment:8 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I think this is just not going to get fixed.
Cc Me!