On Tue, 3 Apr 2001, Brett Lymn stipulated:
> No, it is worse than that - the binaries get installed with dynamic
> library dependencies pointing to a ".libs" directory - I think, it has

Oh dear.

> been a while since I looked at this - anyway, they binaries still are
> in the "run from the local compile directory mode" not the installed
> mode where they should be looking in /usr/pkg/lib as you noted.  The
> linker flags look right to me, I suspect that it stems from some
> lossage with libtool.  At the moment libtool is a mystery to me, I

Not quite. At install time it should be being run with the
`--mode=install' flag, and it looks like it isn't being. (It would be
relinked to point to the right place if --mode=install was running and
working right; that's basically what --mode=install is for.)

> need to get my head around what it does and how it does it - at first
> look it seems an insanely complex hack for not much benefit.

Try making a package that will build shared libraries on AIX and Windows
and HP-UX and Linux and IRIX and NetBSD, then say that again.

(You won't be able to, because you will be in the insane asylum by
then.)

>>Maybe adding the following line to ld.so.conf will help at least the
>>run-time loader.
> 
> No, NetBSD no longer has a ld.so.conf file on architectures that are
> ELF based.  Most NetBSD architectures are ELF or are moving to ELF.

Er, then how do you instruct the dynamic linker to look in particular
directories for shared libraries? Is LD_LIBRARY_PATH and/or LD_RUN_PATH
the only way?

> I can get things linked correctly if I munge the link command not to
> use the .ra file but put the -l<lib> entries on the command line, I

Do you mean .la?

(Don't do that. libtool works this out for itself, but you must run
--mode=install and --mode=finish at the right times.)

-- 
`You're not fun.  I tried to start a holy war, but you replied in
a reasonable manner.' --- Vadik