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/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 this post, but you brought up something related I needed to get out into the public for others to see anyway. ;) I'll definitely try your patch, but I wonder if it will really affect the craziness going on here with DYLD_ -- but maybe with '.' added first might be a workaround for now. Thanks for slogging through this with me. :) _______________________________________________ Devel mailing list Devel@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/devel
