Re: [Xquartz-dev] Strange Xlib error with e17
Thanks Jeremy for the tip. I do see a few libs being loaded from /usr/X11, specifically: dyld: loaded: /usr/X11/lib/libXp.6.dylib dyld: loaded: /usr/X11/lib/libXext.6.dylib dyld: loaded: /usr/X11/lib/libX11.6.dylib dyld: loaded: /usr/X11/lib/libXdmcp.6.dylib dyld: loaded: /usr/X11/lib/libXau.6.dylib The rest are all /opt/X11. Well that would explain it. Full output has 100's of lines: http://pastebin.com/0kbrtben My env has: CFLAGS=-Wall -O2 -arch x86_64 -pipe -I/usr/local/include -I/usr/local/mysql/include -I/opt/X11/include -I/usr/include -I/usr/X11/include LDFLAGS=-arch x86_64 -L/usr/local/lib -L/usr/local/mysql/lib -L/usr/lib -L/opt/X11/lib -L/usr/X11/lib LD_LIBRARY_PATH=/usr/local/lib:/usr/local/mysql/lib:/lib:/usr/lib:/opt/X11/lib:/usr/X11/lib PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig:/usr/X11/lib/pkgconfig In all of them, /opt/X11 comes before /usr/X11. I am wondering, why is the app using libs in /usr/X11 instead of /opt/X11 when my ENV points to /opt/X11 first? How to I force the app to use /opt/X11, beyond my ENV settings?? There are no crash reports. The app appears to hang, but does not crash or leave a report. If I quit X11 during the hang, the app is still running, and I have to kill -9 it. Dave
On Mar 9, 2011, at 17:49, Dave Ray wrote:
My env has:
CFLAGS=-Wall -O2 -arch x86_64 -pipe -I/usr/local/include -I/usr/local/mysql/include -I/opt/X11/include -I/usr/include -I/usr/X11/include LDFLAGS=-arch x86_64 -L/usr/local/lib -L/usr/local/mysql/lib -L/usr/lib -L/opt/X11/lib -L/usr/X11/lib LD_LIBRARY_PATH=/usr/local/lib:/usr/local/mysql/lib:/lib:/usr/lib:/opt/X11/lib:/usr/X11/lib PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig:/usr/X11/lib/pkgconfig
In all of them, /opt/X11 comes before /usr/X11. I am wondering, why is the app using libs in /usr/X11 instead of /opt/X11 when my ENV points to /opt/X11 first? How to I force the app to use /opt/X11, beyond my ENV settings??
Yeah, so I don't know why it's pulling in libs from /usr/X11/lib because it should find everything in /opt/X11/lib ... I'd need to see the build log for the application to tell you, but my guess is that it's something in e17's build system that is prefering /usr/X11
Am 10.03.2011 um 03:01 schrieb Jeremy Huddleston:
Yeah, so I don't know why it's pulling in libs from /usr/X11/lib because it should find everything in /opt/X11/lib ... I'd need to see the build log for the application to tell you, but my guess is that it's something in e17's build system that is prefering /usr/X11
I've seen similar effects when building GNU Emacsen. Although I can see from the CFLAGS' -H and the LDFLAGS' -Wl,-t that during compilation no "foreign" C header file is used and at linking time the proper libraries are used, the final binary is able to use at run time other libraries. This happens on Leopard (Mac OS X 10.5.8). My case concerns up-to-date libotf and libm17n. Out-of-date versions of libotf are usually loaded into memory by "stable" versions of GNU Emacs and / they/ seem to get re-used. I'd wish I could, as in Solaris for example, record the places where to find the shared libraries, instead of fishing for the right one in a muddy pool. -- Greetings Pete Genius may have its limitations, but stupidity is not thus handicapped. – Elbert Hubbard
On Mar 10, 2011, at 01:54, Peter Dyballa wrote:
Am 10.03.2011 um 03:01 schrieb Jeremy Huddleston:
Yeah, so I don't know why it's pulling in libs from /usr/X11/lib because it should find everything in /opt/X11/lib ... I'd need to see the build log for the application to tell you, but my guess is that it's something in e17's build system that is prefering /usr/X11
I've seen similar effects when building GNU Emacsen. Although I can see from the CFLAGS' -H and the LDFLAGS' -Wl,-t that during compilation no "foreign" C header file is used and at linking time the proper libraries are used, the final binary is able to use at run time other libraries. This happens on Leopard (Mac OS X 10.5.8). My case concerns up-to-date libotf and libm17n. Out-of-date versions of libotf are usually loaded into memory by "stable" versions of GNU Emacs and /they/ seem to get re-used.
I'd wish I could, as in Solaris for example, record the places where to find the shared libraries, instead of fishing for the right one in a muddy pool.
Both models have their benefits and pitfalls. In the Solaris case, you run into the problem of linking against a newer version of the library and the loader using an older version because it was earlier in the search path. I used to feel as you do, but after being a Gentoo developer for ~5 years and an Apple developer for ~3 years, I really prefer this approach due to its explicity.
participants (3)
-
Dave Ray
-
Jeremy Huddleston
-
Peter Dyballa