On Tue, Apr 04, 2000 at 06:11:16PM -0500, John Darrow wrote:
> On Tue, Apr 04, 2000 at 03:33:07PM -0500, erh@nimenees.com wrote:
> > 	It already ends up being a runtime-type link, just with an
> > unusual name.
> 
> That's exactly what I said.  Apparently, our ld.new does strip off the
> path, as seen from an ELF compile of pkgsrc/editors/pico:
> /usr/pkg/bin/pkglibtool-ELF-1.2p2 cc -O2    -Dneb -DJOB_CONTROL -DPOSIX -DMOUSE main.o libpico.la  -ltermcap -o pico
> cc -O2 -Dneb -DJOB_CONTROL -DPOSIX -DMOUSE main.o -Wl,--rpath -Wl,/usr/pkg/lib .libs/libpico.so -ltermcap -o .libs/pico
	doh!  yes, you're right.  I was forgetting to add -soname when
building the lib.  Once I did that it uses just the name instead of a path.

> Apparently (from your comments) the old ld doesn't do the same stripping,
> but libtool hands it a different command line:
	I'm pretty sure I'm using the new one.
# ld -v
GNU ld version 2.9.1 (with BFD 2.9.1)
#
	ELF, current as of a couple weeks ago.

It would be nice if ld did actually strip off the path if the library
doesn't have soname set.  Of course, that would mean that it would need
to set the rpath in order for the binary to continue working.
(could you check if omitting soname does actually result in the behavior
I'm describing?)

> /usr/pkg/bin/pkglibtool-a.out-1.2p2 cc -O2    -Dneb -DJOB_CONTROL -DPOSIX -DMOUSE main.o libpico.la  -ltermcap -o pico
> cc -O2 -Dneb -DJOB_CONTROL -DPOSIX -DMOUSE main.o -R/usr/pkg/lib -L.libs -lpico -ltermcap -o .libs/pico
> 
> Still, it works.  Or you'd have a lot of angry pico and pine lovers storming
> your door...
	Yes, compiling it works, but you can't run it until you install
the libs.

> > > gcc -o foo foo.c -L./.libs -lfoo -Wl,-rpath,/usr/local/lib
> > > On both a.out and elf, this will produce an executable which will just
> > > work, without the need of either ldconfig or LD_LIBRARY_PATH.
> > 	uh, no.  This doesn't work.  Try it.  You're going to have to
> > set LD_LIBRARY_PATH in order for "./foo" to be able to find the
> > library.  
> I just did.  It works fine.  On both 1.4.2 (a.out, uses gnusrc/usr.bin/ld)
> and 1.4V (ELF, uses gnusrc/usr.bin/ld.new), both on i386.  No /testlibs in
> /etc/ld.so.conf, no LD_LIBRARY_PATH set.  I'll include the test setup at
> the end of this message.
...
> [215] root@abigail:ttyp0:/var/tmp/shlibex:# cp -p .libs/libshfunc.so.0.0 /testlibs
...
	Well sure it works if you install the libraries.  I think we might
be talking past each other a bit here.  I agree that you can build with -L,
run with -rpath once libs are installed, but if you try to build something
that needs to run a util using a not-yet-installed library during the build
then it won't work.

There are several ways I can see to get it to work:
1) Install the libs before using the util.  (potentially major mods to build)
2) Set LD_LIBRARY_PATH.	 (build modifications, though not as severe)
3) Add -rpath,...	(more build modifications)
4) Have ld automatically set rpath from -L... if -rpath isn't set explicitly.
		(no build mods, allows more apps to build out of the box)


> Yes, on SunOS, ld adds the -L options to a default runtime search path
> unless -rpath is given explicitly.  See that same gnu ld man page for one
> reason why that might _not_ be a good thing, and I've already stated another
	er, I must be looking in the wrong place.  Not sure which part of
the man page you're talking about.

> (useless runtime lookups of directories such as .libs which aren't there.)
> 
> Basically, the whole -rpath thing is the ELF way of doing things, and that's
> the direction the UNIX world seems to be moving.  Given that there are tools
> available (such as libtool) which make it much easier to get things right,
> we should be encouraging program authors to doing things the correct way,
> instead of putting in wasteful hacks to support those who don't.
	Is it really that wasteful?  In the common cases a package will either
have the libs it uses installed already and use a -L<installed lib path> or
it will know that it needs to use -rpath and that will disable any rpath
additions from -L args.  The programs which will use the feature usually
won't be installed but if they are having the extra rpath directory in this
one case won't be extremely wasteful.

eric