On Wed, Feb 27, 2008 at 11:36:17AM -0800, Keith M Wesolowski wrote: > On Wed, Feb 27, 2008 at 01:24:41PM -0600, Nicolas Williams wrote: > > > That'd be great, but it'd also be wrong. Why should a dependency's > > runpath have anything to do with the consumer's runpath? The consumer's > > You're assuming the Solaris way of linking: each object's RUNPATH and > DT_NEEDED are sufficient for resolving all its symbols. That is, we > use -zdefs.
I am assuming that the result should conform to the Solaris way of linking. That libtool doesn't is a problem. I am not assuming that libtool conforms... I _know_ it doesn't. > The way GNU/Linux systems have done this for ages (and still do, for > all I know), and the way libtool seems to assume everything works, is > that shared objects have no DT_NEEDED entries and no meaningful > RUNPATH; instead the .la files accumulate this information and libtool > encodes all of it into the executable binaries that depend on these > libraries. *sigh* > This is one of the many reasons I consider libtool too toxic to be > used at all. But I've no control over that here. Unless I write an entirely new makefile for SQLite3 on Solaris, but I doubt that I can push that upstream.
