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. _______________________________________________ Xquartz-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
