libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DESTDIR install and OpenBSD


From: Jacob Meuser
Subject: Re: DESTDIR install and OpenBSD
Date: Tue, 31 Jan 2006 18:06:49 -0800
User-agent: Mutt/1.4.2i

On Tue, Jan 31, 2006 at 10:21:34AM +0100, Ralf Wildenhues wrote:
> Hi Jacob,
> 
> * Jacob Meuser wrote on Tue, Jan 31, 2006 at 08:14:43AM CET:
> > On Tue, Jan 31, 2006 at 04:33:10AM +0100, Ralf Wildenhues wrote:
> > > * Jacob Meuser wrote on Fri, Jan 27, 2006 at 04:16:22AM CET:
> > > > >
> > > > >  If `$libdir/$linklib' happens to actually exist but
> > > > > be the wrong thing, it fails to work around; 
> > > > 
> > > > true.  however, this is really close to the same problem as already
> > > > exists wrt library search paths.  so it's not creating any more of
> > > > a problem than already exists.
> 
> > > > will need to be reexamined soon though :)
> > > 
> > > Why?  Because we keep mumbling about not linking against indirect
> > > deplibs?  ;-)
> > 
> > because hopefully libtool will soon instruct the linker to use correctly
> > ordered library search paths.
> 
> Ah.  Are you implying that the ordering of the uninstalled paths has an
> impact on this problem?  I previously thought it had not.  If there is
> another ordering problem, I'd like to know about it.

no, but it is sort of related.  it checks for $libdir/$linklib instead
of $inst_prefix/$libdir/$linklib.

>  Recent patches
> have shown me once again that it is crucial to have good tests in our
> test suite to prevent mistakes from returning.  They are hard, though:
> I have not yet been able to come up with a system-independent version
> of the `link-order.test' that exposes the very issue originally observed.
> 
> > > > > if it does not exist,
> > > > > libtool fails to add hardcoding for the respective library, resulting 
> > > > > in
> > > > > execution startup failure.
> > > > 
> > > > it's not a problem on OpenBSD, because OpenBSD doesn't rely on the
> > > > path being hardcoded.  in fact, it it preferred that the paths are
> > > > not hardcoded.
> > > 
> > > I'd like this statement clarified a bit, to one (or more) of these:
> > > - OpenBSD developers prefer to not have any hardcoded paths in libraries.
> > > - OpenBSD developers prefer to not have any hardcoded paths in 
> > > executables.
> > 
> > it is preferred that someone could install a binary package an any
> > prefix, and have it work.  for example, the official packages are built
> > with --prefix=/usr/local, but someone could install a binary openbsd
> > package into /opt.
> 
> How would you make sure programs find their libraries and modules
> automatically?  /usr/local/lib is neither in the default library search
> path nor the default module (dlopen) search path.

/usr/local/lib is added to the default search path by /etc/rc.  it
could be changed to add /opt/lib, or any other directory as well.

> I can understand the desire from a ports/distribution developer
> standpoint very well, but from an end-user standpoint, I expect libtool
> to cause my created programs to function when installed, without things
> such as setting LD_LIBRARY_PATH, for example.

agreed.

> If OpenBSD were to desire not to link against indirect deplibs either,
> it would be necessary to add DT_RPATH entries to libraries, too, not
> just programs.
> 
> > > - OpenBSD compiler and/or linker and/or runtime linker are patched to
> > >   not honor hardcoding arguments (--rpath).
> > 
> > it does honor --rpath
> 
> > it does honor hardcoded paths in libraries.  for example:
> *snip*
> > and it does honor hardcoded paths in binaries:  for example:
> *snip*
> 
> Which?  The link editor or the runtime linker?  It's necessary to be
> pedantic here.  My own observations are that both do:
> - The link editor is basically some version of GNU binutils ld; it does
>   honor rpaths for locating additional required libraries that are not
>   listed on the command line.
> - The runtime linker (ld.so) also obeys rpaths in libraries.
> 
> See this example:
> 
> mkdir sub
> cd sub
> echo 'int a() { return 0; }' > a.c
> gcc -fPIC -c a.c
> gcc -shared -o liba.so a.o
> cd ..
> echo 'extern int a(); int b() { return a(); }' > b.c
> gcc -fPIC -c b.c
> gcc -shared -o libb.so b.o -Lsub -la -Wl,-rpath,`pwd`/sub
> echo 'extern int b(); int main() { return b(); }' > m.c
> gcc -c m.c
> # the next two lines show that ld looks for liba.so
> # (and fails because we hide it):
> mv sub sub-moved
> gcc -o m m.o -L. -lb -Wl,-rpath,`pwd`
> | /usr/bin/ld: warning: liba.so, needed by ./libb.so, not found (try using 
> -rpath or -rpath-link)
> | ./libb.so: undefined reference to `a'
> | collect2: ld returned 1 exit status
> # the next lines shows that ld finds liba.so through RPATH in libb.so:
> mv sub-moved sub
> gcc -o m m.o -L. -lb -Wl,-rpath,`pwd`
> # the next line shows that ld.so finds liba.so:
> ./m; echo $?
> | 0
> objdump -p m | egrep 'NEEDED|RPATH'
> |  NEEDED      libb.so
> |  NEEDED      libc.so.38.4
> |  RPATH       /tmp/test
> objdump -p libb.so | egrep 'NEEDED|RPATH'
> |  NEEDED      liba.so
> |  RPATH       /tmp/test/sub
> 
> > > - the OpenBSD runtime linker does not honor hardcoded paths in libraries.
> > > - the OpenBSD runtime linker does not honor hardcoded paths in libraries
> > >   nor executable.
> > 
> > it does honor both.  the user should be able to do this if he so
> > chooses.
> 
> OK.
> 
> > we don't want full hardcoded paths like /usr/local/lib/libfoo.so.x.y.
> > RPATH is not such a big deal.
> 
> Ah!  I've never understood that it is paths in DT_NEEDED that you
> dislike (as opposed to paths in DT_RPATH).  Well, yes, I can understand
> this very well, now that I've finally understood this.  ;-)

yes, this is the main concern.

> Well, libtool currently simply does the wrong thing on OpenBSD then.
> Let's fix this (self adds more notes to testsuite TODO list).

good :)

> > keeping in mind that we want users to be able to install binary
> > packages in any prefix, hardcoding paths is really never useful,
> > at least as far as building packages goes.
> 
> Pending my question above.

which one? :)

> > there may well be differences in the way we want things to work in
> > our ports tree, and the way the average user would expect things
> > to work.
> 
> Sure.  I understand the ports system has machinery in place to override
> package's libtool scripts, so this is a solved problem (except for the
> occasional nuisance that the innocent user will find that he cannot
> reproduce a package build outside-of-ports to match the ports one;
> luckily that is not too much of an issue ATM, so let's not worry about
> it).

true.  it's pretty easy to tell people to install the libtool port and
use 'make LIBTOOL=/usr/local/bin/libtool' if they are having libtool
related problems.  it's fairly rare that this comes up though.

> > > IIRC OpenBSD will not use the indirect deplibs issue because its runtime
> > > linker does not load DT_NEEDED dependencies.  Right?
> > 
> > AFAICS, this is not currently true.  this may have been the case at
> > one time, but there has been a bit of work to the runtime linker over
> > the past few years.
> 
> Agreed.  See my test above which disproves this.

good.  I think we have a better understanding of the issues now.

-- 
<address@hidden>

> Cheers,
> Ralf
> 
> 
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool




reply via email to

[Prev in Thread] Current Thread [Next in Thread]