Re: ct-lib unit tests link statically

James K. Lowden wrote:
> Johnny C. Lam wrote:
>> Setting LD_LIBRARY_PATH will override any embedded rpath 
> 
> Huh, so it does!  
> 
> OT: Now I *really* don't know why NetBSD doesn't ship by default with a
> ld.so.conf that includes /usr/local/lib and /usr/pkg/lib.  I had been
> given to understand that relying on RPATH was more secure than using
> LD_LIBRARY_PATH but, because the environment variable overrides, any user
> can cause any shared object to be used.  
> 
> I think maybe I should simplify my life by adding usr/local/lib and
> /usr/pkg/lib to /etc/ld.so.conf.  

Note that one important disadvantage is that you can't have different 
libraries with the same name in the directories listed in /etc/ld.so.conf.

There is an FAQ about ELF on NetBSD, but the relevant paragraph is here:

     http://www.netbsd.org/docs/elf.html#elf-ldconfig-revisited

>> How are you verifying that the wrong shared libraries are being used?
> 
> See above.  datafmt is a ct-lib unit test.  readelf(1) shows the embedded
> RPATH.  The first part -- /usr/local/lib:/usr/pkg/lib -- comes directly
> from LDFLAGS.  ldd(1) shows datafmt is dynmically linked to
> /usr/local/lib/libct.so.4.  

Okay.  The libtool-generated scripts that call the programs in .libs 
should correctly override the embedded RPATH via LD_LIBRARY_PATH (or 
DYLD_LIBRARY_PATH on MacOS), though I'm not 100% certain that it will 
work on every platform (not every platform has a way to embed or 
override shared library information).

	Cheers,

	-- Johnny C. Lam