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: tsi@xxxxxxxxxxx |
| 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@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel
