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 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.  :)

Eh.  All I did was a fire-side read of the ld(1) man page.

Anyway, I've already committed a change for this.  You won't need to 
change anything.

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.