[Xquartz-dev] Strange Xlib error with e17

[Jeremy Huddleston]

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.