Re: Fix for prefixed installs requiring relink

[Wesley W. Terpstra]

On Sun, Oct 22, 2000 at 05:53:36PM -0200, Alexandre Oliva wrote:
> On Oct 22, 2000, "Wesley W. Terpstra" <address@hidden> wrote:
> 
> > The relink of libbar.la uses -L/usr/lib and -lfoo. Assuming that you
> > are compiling the package in your home directory and there is no
> > /usr/lib/libfoo.*, the relink will fail.
> 
> And, if there is, you'll get your library linked with the wrong
> version of libfoo, which may also be troublesome.
Yes, actually, my patch doesn't solve this case very well. :-(

For some reason I didn't look into, libtool gets a -L/usr/lib in there before
my -L/home/terpstra/foo/src/tmp/usr/lib. Something else adds it before mine,
however, this seems only to be the case with /usr/lib and I thought that at
least building in the case where it's not yet installed (the one I was
concerned with) was better than nothing.

If someone can find the place libtool inserts the -L/usr/lib and move it
after the search paths added when scanning depends, that'd be the solution
to this case.

> The problem is that, on many operating systems, there's no such thing
> as -rpath or -R, that can be used by libtool to encode the a library
> search path.  On such systems, that search path is given in
> environment variables (no problem here), 
They're not a problem b/c no relink is required?

> -L switches or library pathnames.  In the latter two cases, libtool 
> must either refuse to install a library with a different installation 
> prefix, because there's no way to do it right, 

Shitty, if some systems infer the search path from a -L, you're right, my
patch will produce libraries searching for their depends in some maintainers
temporary packaging directory. :-( However, it's trivial to catch these
systems in the libtool script. Case: computer is of these types &
inst_prefix_dir != "", result: 'You can't do this.' From a package
maintainers point of view that shouldn't be a problem b/c it is impossible
to do in a tmp dir anyways, so we're not taking anything away. If necessary,
they've always got static. ;-)

> or emit a warning and proceed doing possibly the wrong thing.
Maybe this is a philosophical difference, but I think just warning is
insufficient. I think it should quit with an error telling you that we think
this is impossible on their architecture. However, also tell them about a
command-line option they can use to force it to do the wrong thing.

> > My included patch solves this problem with one stipulation: You can
> > install dependent libraries anywhere as long as the complete libdir
> > path is on the end. Hence the above example would work, while
> > `pwd`/tmp/lib/libfoo.la would not as there is no usr/lib on the end.
> 
> Thanks for your patch.  Unfortunately, I don't expect to have time to
> look into it in the near future; maybe some other maintainer does.
> This is a problem that has bothered me in libtool for a long time, but
> I still hadn't had a chance to tackle it.
Well, I'm glad that by helping myself package a program I've helped you
guys, if only a bit.

--
To recap then, maybe three more changes are in order:
1) Move the code that's sticking in -L/usr/lib after the depedency library
scan
2) Add a -force-prefixed-relink command line option to do the impossible
3) In the relink section, ensure that for computers that use -L or library
pathnames to get the search path, either -force-prefix-relink is true or
inst_prefix_dir is null. If either fail, bail out with a nasty informative
message.

Any comments? After I do some house cleaning I may look into doing these,
but for options #3 I need a way to identify computers that use -L or the
library path for creating their search path.

-- 
Wesley W. Terpstra <address@hidden>
Javien Canada Inc. - Linux Developer

pgpKZVGVCLGri.pgp
Description: PGP signature