On Wed, Mar 13, 2002 at 10:53:12AM -0500, Todd Vierling wrote:
> On Tue, 12 Mar 2002, Johnny Lam wrote:
> 
> : Is there a difference between the following commands?
> :
> : (a) cc -o libbar.so.0.0 bar.o -Wl,-R/usr/pkg -L/usr/pkg -lfoo
> : (b) cc -o libbar.so.0.0 bar.o -Wl,-R/usr/pkg /usr/pkg/libfoo.so
> 
> There's no difference, but you made three unrelated mistakes in these
> examples:
> 
> * /usr/pkg/lib, not /usr/pkg
> * the -soname argument is missing for libbar
> * the -shared option is missing

Yes, thanks for pointing those out.  I was typing these lines off the
top of my head, and I forgot a few essential bits.

> : Similarly, on an a.out system, suppose I have the following files:
> :
> : 	/usr/pkg/lib/libfoo.so.0.0
> :
> : Is there a difference between the following commands?
> :
> : (a) ld -Bshareable -o libbar.so.0.0 bar.o -R/usr/pkg -L/usr/pkg -lfoo
> : (b) ld -Bshareable -o libbar.so.0.0 bar.o -R/usr/pkg /usr/pkg/libfoo.so.0.0
> 
> `Test it.'  I believe there is a difference, but I don't have a system
> available on which to check.

I was able to test on a NetBSD-1.5.1/mac68k machine, and they do both
generate the shared library libbar.so.0.0; however, I'm not sure how to
tell what ware the interlibrary dependencies recorded in libbar.so.  On
the ELF system, I was able to run "ldd libbar.so" and discover the
dependencies, but that doesn't work on the a.out system.  Do I have to
link an executable against libbar.so and run "ldd" on the executable to
discover the dependencies?

> FROM MEMORY ONLY, may be incorrect:  The a.out linker, in case (a), will
> encode a major number and minimum minor number for use by the runtime
> linker.  However, if a full filename as in case (b) is given with
> .major.minor, only that specific library pathname will be usable -- any
> library with an incremented minor number will not link.

Given how pkgsrc works, that would be bad.  I'll try some tests on the mac68k,
but will those results be representative for all NetBSD/a.out platforms?

> There's another possible difference, but you'd need to test it, as I've
> never checked NetBSD's a.out linker for this:  Some linkers will encode the
> full path provided in case (b) into the dependent, rather than just a
> libname, resulting in a binary that has an absolute path (which would be bad
> for multiple libtooled libraries built together in one tree).  In such
> cases, rpath and LD_LIBRARY_PATH are unusable for finding the shared object
> if it moves.

Yes, I've read through ltmain.in many, many times, and this is taken care of
for those other linkers.  I'm only worried about linkers like NetBSD's that
don't hardcode library pathnames unless they're specified in a -R or --rpath
on the command line.

> : I am trying to solve a problem involving the use of libtool in pkgsrc.
> 
> Could you describe the problem?

It involves the interaction between libtool and buildlink.  When a package
uses libtool to create two shared libraries libbar.so and libfoo.so, one
depending on the other as above, and then uses libtool to install them into
/usr/pkg/lib, then libbar.so is relinked prior to the actual installaion so
that it can find libfoo.so in /usr/pkg/lib.  Currently, it relinks by doing
(a), but I want it to do (b) instead, as then I don't accidentally link
against other libraries accidentally as in the following scenario:

	User has:

		/usr/lib/libssl.so		[system supplied ]
		/usr/lib/libcrypto.so		[  OpenSSL-0.9.5a]

		/usr/pkg/lib/libssl.so		[pkgsrc-supplied ]
		/usr/pkg/lib/libcrypto.so	[  OpenSSL-0.9.6b]

	libbar.so explicitly needs the old OpenSSL libraries, and has
	the following dependencies:

		libbar.so: /usr/pkg/lib/libfoo.so.0.0
		           /usr/lib/libssl.so.?.?
		           /usr/lib/libcrypto.so.?.?

	The relink command for libbar.so does:

		cc -shared -Wl,-soname -Wl,libbar.so.0 -o libbar.so.0.0 \
			-L/usr/pkg/lib -lfoo -lssl -lcrypto

But this relink command will link against the wrong OpenSSL libraries.  If
instead, it executed:

		cc -shared -Wl,-soname -Wl,libbar.so.0 -o libbar.so.0.0 \
			/usr/pkg/lib/libfoo.so -lssl -lcrypto

then I could control which libraries to link against more accurately.

	Cheers,

	-- Johnny Lam <jlam@jgrind.org>