Re: Link problems with xedit, may be Darwin-only(?)
On Tue, 24 Apr 2007, SciFi wrote: On Tue, 24 Apr 2007 08:08:24 -0600, Marc Aurele La France wrote: On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] <<<< I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather & connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Holy guacamole this is getting too strange. Please bear with me, I really need to explain some things that are related to your reply. For background: Even though Apple's current docs say they would honour LD_LIBRARY_PATH (probably due to their promise to be more Linux-friendly), in actuality we've never seen it work. Instead we must set DYLD_LIBRARY_PATH for Darwin/OSX systems. Now to the meat of this issue: In my /usr/local/lib are the GNU MP 4.1.2 libraries named -- you guessed it -- libmp.a & libmp.dylib (plus symlinks to the versioned names). AFAICT this is their latest version. I need it for some other projects I think related to the FFT libs which again are needed for some other projects. Talk about a naming clash. I could try putting /usr/X11R6/lib ahead of /usr/local/lib for the DYLD_ env just for starting X11 and tasks it spawns, but we then have a crazy problem if we include /usr/X11R6/lib AT ALL in that path string -- anywhere: late, early, first, middle, last -- it makes no difference. The biggest crazy problem is that this will disable the Macromedia Flash plugin for any & all web-browsers: 2007-04-02 05:36:26.495 firefox-bin[6726] CFLog (21): Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: error code 4, error number 0 (Symbol not found: _gluTessCallbackCFM Referenced from: /System/Library/Frameworks/AGL.framework/Versions/A/AGL Expected in: /usr/X11R6/lib/libGLU.dylib ) Another crazy problem is that we see the console printing this message for _any-and-all_ tasks using that DYLD_ setting: dyld: warning DYLD_ setting caused circular dependency in /usr/X11R6/lib/libGL.dylib Some weeks ago I opened problem #5104136 at http://bug-report.apple.com/ to log these interrelated issues with DYLD_LIBRARY_PATH and /usr/X11R6/lib. (By the nature of the 'free' ADC account, the bug-reports aren't made public, searchable, or otherwise sharable. If you want I could c&p the discussion going on there.) What's even more strange is that I cannot find any file whatsoever *anywhere* with the string 'gluTessCallbackCFM' -- even in the calling libs (AGL Frameworks & Flash plugin files)!!! (hmm I am assuming the symbol tables are not encoded with 16-bit ASCII/UTF like with some M$ stuff...) That happens with libGL[U].dylib coming from Apple's X11 on the Tiger install DVD with their updates from a few months ago. It also happens with the _new_ libGL[U].dylib being built from current XFree86-cvs!!! The only way to fix this for real is to remove /usr/X11R6/lib from the DYLD_ path entirely. But I want my test env to be sure to use my newer builds of libs in /usr/local/lib no matter what. (There are settings in each user's ~/.MacOSX/environment.plist that control these paths for the Finder and GUI stuff itself. To get the system itself to find stuff there first, we set+export DYLD_ in the /etc/rc.common script which ought to propagate to all other boot tasks. For the system GUI stuff, we edit root's ~/.MacOSX/environment.plist as well. This way we get the whole ball of wax to use e.g. the latest iconv+intl libs and many many many others.) So my test env isn't going to be able to scan /usr/X11R6/lib at all until/unless Apple fix this bug. But maybe that isn't the real problem with this particular xf86 build problem. Do you think I should add '.' as the very first path to DYLD_ -- I don't think it is implicit? (Right now I actually do have '.' as the very last path here.) Didn't mean to get so long with
Re: Link problems with xedit, may be Darwin-only(?)
On Tue, 24 Apr 2007 08:08:24 -0600, Marc Aurele La France wrote: > On Sun, 22 Apr 2007, SciFi wrote: >>> On Sat, 14 Apr 2007, Marc Aurele La France wrote: >>>> On Wed, 11 Apr 2007, SciFi wrote: > >>>>> 4. Link problems with xedit, may be Darwin-only(?) > >>>> Possibly. > >>>>> Build Log snip: > >>>>> [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre >>>>> -lm -L/usr/X11R6/lib >>>>> /usr/bin/ld: Undefined symbols: > >>>>[...] > >>>>> collect2: ld returned 1 exit status >>>>> [...] >>>>> <<<< > >>>> I'd like to see the _complete_ command line that fails, not just the >>>> tail end of it. > >>> Anything more on this? Is this related to your GNU make upgrade? > >> oh I just saw this ... having weather & connection problems etc. >> here... > >> No ... as I mentioned I've seen this kind of problem with other >> projects albeit rarely. I'd blame the Apple linker on such occasions >> for losing the symbols, whatever is causing it we have no idea. The >> symbols _are_ there in the .a files. (IIRC the libdvdread project does >> this, too, and there are others, all usually fixed by including the .a >> files...) > > One possibility here is that it is finding a libmp.dylib in a > LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then > the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. > > Marc. Hi, Holy guacamole this is getting too strange. Please bear with me, I really need to explain some things that are related to your reply. For background: Even though Apple's current docs say they would honour LD_LIBRARY_PATH (probably due to their promise to be more Linux-friendly), in actuality we've never seen it work. Instead we must set DYLD_LIBRARY_PATH for Darwin/OSX systems. Now to the meat of this issue: In my /usr/local/lib are the GNU MP 4.1.2 libraries named -- you guessed it -- libmp.a & libmp.dylib (plus symlinks to the versioned names). AFAICT this is their latest version. I need it for some other projects I think related to the FFT libs which again are needed for some other projects. Talk about a naming clash. I could try putting /usr/X11R6/lib ahead of /usr/local/lib for the DYLD_ env just for starting X11 and tasks it spawns, but we then have a crazy problem if we include /usr/X11R6/lib AT ALL in that path string -- anywhere: late, early, first, middle, last -- it makes no difference. The biggest crazy problem is that this will disable the Macromedia Flash plugin for any & all web-browsers: 2007-04-02 05:36:26.495 firefox-bin[6726] CFLog (21): Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: error code 4, error number 0 (Symbol not found: _gluTessCallbackCFM Referenced from: /System/Library/Frameworks/AGL.framework/Versions/A/AGL Expected in: /usr/X11R6/lib/libGLU.dylib ) Another crazy problem is that we see the console printing this message for _any-and-all_ tasks using that DYLD_ setting: dyld: warning DYLD_ setting caused circular dependency in /usr/X11R6/lib/libGL.dylib Some weeks ago I opened problem #5104136 at http://bug-report.apple.com/ to log these interrelated issues with DYLD_LIBRARY_PATH and /usr/X11R6/lib. (By the nature of the 'free' ADC account, the bug-reports aren't made public, searchable, or otherwise sharable. If you want I could c&p the discussion going on there.) What's even more strange is that I cannot find any file whatsoever *anywhere* with the string 'gluTessCallbackCFM' -- even in the calling libs (AGL Frameworks & Flash plugin files)!!! (hmm I am assuming the symbol tables are not encoded with 16-bit ASCII/UTF like with some M$ stuff...) That happens with libGL[U].dylib coming from Apple's X11 on the Tiger install DVD with their updates from a few months ago. It also happens with the _new_ libGL[U].dylib being built from current XFree86-cvs!!! The only way to fix this for real is to remove /usr/X11R6/lib from the DYLD_ path entirely. But I want my test env to be sure to use my newer builds of libs in /usr/local/lib no matter what. (There are settings in each user's ~/.MacOSX/environment.plist that control these paths for the Finder and GUI stuff itself. To get the system itself to find stuff there first, we set+export DYLD_ in the /etc/rc.common script which ought to propagate to all other boot tasks. For the system GUI stuff, we edit root's ~/.MacOSX/environment.plist as well. This way we get the whole ball of wax to use e.g. the latest iconv+intl libs and many many many others.) So my test env isn't going to be able to scan /usr/X1
Re: Link problems with xedit, may be Darwin-only(?)
On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] <<<< I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather & connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
> On Sat, 14 Apr 2007, Marc Aurele La France wrote: >> On Wed, 11 Apr 2007, SciFi wrote: > >>> 4. Link problems with xedit, may be Darwin-only(?) > >> Possibly. > >>> Build Log snip: > > >>> [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre >>> -lm -L/usr/X11R6/lib >>> /usr/bin/ld: Undefined symbols: > >> [...] > >>> collect2: ld returned 1 exit status >>> [...] >>> <<<< > >> I'd like to see the _complete_ command line that fails, not just the >> tail end of it. > > Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather & connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) Let me cvs-up to get your other commits (soon as they get pushed to the public server) and give it another try. > Marc. Thanks. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] <<<< I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] <<<< I'd like to see the _complete_ command line that fails, not just the tail end of it. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Link problems with xedit, may be Darwin-only(?)
Hi,
(This is part of a collection of patches and workarounds I have
for consideration for problems in the build process in current
cvs. I'll just briefly describe each patch(-set) below, and if
needed will put them into bugzilla separately with more details.)
4. Link problems with xedit, may be Darwin-only(?)
Build Log snip:
>>>>
[...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm
-L/usr/X11R6/lib
/usr/bin/ld: Undefined symbols:
_mpi_clear
_mpr_clear
_mpi_getsize
_mpi_getstr
_mpi_init
_mpi_seti
_mpi_sgn
_mpr_getstr
_mp_set_calloc
_mp_set_free
_mp_set_malloc
_mp_set_realloc
_mpi_add
_mpi_addi
_mpi_and
_mpi_cmp
_mpi_cmpi
_mpi_com
_mpi_divi
_mpi_divqr
_mpi_fiti
_mpi_getd
_mpi_geti
_mpi_ior
_mpi_mod
_mpi_modi
_mpi_mul
_mpi_muli
_mpi_neg
_mpi_rem
_mpi_remi
_mpi_set
_mpi_setd
_mpi_sqrt
_mpi_sub
_mpi_subi
_mpi_xor
_mpr_add
_mpr_addi
_mpr_canonicalize
_mpr_cmp
_mpr_cmpi
_mpr_div
_mpr_divi
_mpr_fiti
_mpr_getd
_mpr_init
_mpr_inv
_mpr_mul
_mpr_muli
_mpr_set
_mpr_setd
_mpr_seti
_mpr_sub
_mpr_subi
_mpi_setstr
collect2: ld returned 1 exit status
[...]
<<<<
This occurs in at least two xedit-related modules during the build.
To recreate:
Build xf86 with latest XCode (Apple-provided gcc, ld, etc.).
Possibly related env-vars:
export MACOSX_DEPLOYMENT_TARGET="10.4"
export SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk"
export SDK="${SDKROOT}"
...and maybe others...
$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
[...]
$ uname -a
Darwin 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST
2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3
Darwin
(OSX 10.4.9 running on a Dual G5 2.7GHz with 3.5GB of matched-pair
SDRAM and more...)
Discussion:
The included libs were previously built, they really are there,
plus the correct -L/-l options are in the [I]makefiles as can be
seen in the snip above. But sometimes the "visibility" attributes
of symbols get lost for unknown reasons. Other projects also have
this problem, albeit rarely, but always recreatable when it does
happen.
To prove the symbols were compiled but possibly not placed in the
dylibs properly, we can instead include the related .a files as
with this patch:
>>>>-cut->>>>
--- xc/programs/xedit/lisp/Imakefile_orig 2005-10-14 10:17:32 -0500
+++ xc/programs/xedit/lisp/Imakefile2007-04-11 01:12:28 -0500
@@ -115,7 +115,7 @@
$(SNPRINTF_DEFS) $(SYS_DEFINES) $(SIGNAL_DEFINES)
DEPLIBS = mp re
INCLUDES = -I.. -Imp -Ire -I../.. $(MISC_INCLUDES)
-LOCAL_LIBRARIES = -L. -llisp -Lmp -lmp -Lre -lre -lm $(DLLIB)
+LOCAL_LIBRARIES = ./liblisp.a -L. -llisp ./mp/libmp.a -Lmp -lmp ./re/libre.a
-Lre -lre -lm $(DLLIB)
#ifdef IHaveSubdirs
ForceSubdirs($(SUBDIRS))
--- xc/programs/xedit/Imakefile_orig2005-10-14 10:17:32 -0500
+++ xc/programs/xedit/Imakefile 2007-04-11 01:17:27 -0500
@@ -12,7 +12,7 @@
#define PassCDebugFlags CDEBUGFLAGS="$(CDEBUGFLAGS)"
SUBDIRS = lisp
- LISPLIBS = -Llisp -llisp -Llisp/mp -lmp -Llisp/re -lre
+ LISPLIBS = ./lisp/liblisp.a -Llisp -llisp ./lisp/mp/libmp.a -Llisp/mp
-lmp ./lisp/re/libre.a -Llisp/re -lre
LISP_SRC = lisp.c
LISP_OBJ = lisp.o
<<<<-cut-<<<<
See what I mean? Now the linker is happy.
As a quick local fix so not to need to regenerate them, the
Makefiles related to the two Imakefiles shown in the patch can be
edited by hand in a similar manner, too. I can't provide a patch
because your generated Makefiles will quite likely be completely
different than mine. ;)
Thanks for any help. :)
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
