Re: link_all_deplibs feature

[Alexander Leidinger]

Quoting Ralf Wildenhues <address@hidden> (Fri, 7 Sep 2007 20:37:38 +0200):

BTW: The reason why I didn't got the mails before was a problem with
the DNS server which hosts leidinger.net. The domainkey TXT entry was
not split up into multiple 255-character parts. I removed the key from
DNS now until the provider fixes the problem with his configuration
interface, so mails should flow correctly now even via servers which
didn't had the MX entry cached.

> * Alexander Leidinger wrote on Fri, Sep 07, 2007 at 07:43:56PM CEST:
> > Quoting Ralf Wildenhues (Fri, 7 Sep 2007 14:56:46 +0200):
> > > * Alexander Leidinger wrote on Thu, Sep 06, 2007 at 10:23:32AM CEST:
> > > >
> > > > In revision 1.47.2.12 (branch-1-5) of ltdl.m4 you set 
> > > > libltdl_cv_sys_dlopen_deplibs to yes for DragonFlyBSD and FreeBSD. This 
> > > > is 
> > > > because the runtime linkers recursively open dependencies (libs) 
> > > > themself. 
> > > > libtool.m4 can be changed accordingly to not include recursive 
> > > > dependencies 
> > > > at link time too. This was not done.  
> > > 
> > > FYI, in GNU Libtool currently no system get link_all_deplibs set to no.
> > > (Some distributions change this in their version; Debian for example.)
> > > This is because link_all_deplibs=no exposes some bugs in libtool, that
> > > are rather nontrivial to fix.  The HEAD testsuite has tests for them
> > > in libtool/tests/indirect_deps.at (if you like I can explain the issues,
> > > they have been reported several times).
> > 
> > That would be nice. I could determine if there's something which
> > affects FreeBSD or not.
> 
> For one, execution of an uninstalled program (resp. its libtool wrapper)
> that has uninstalled indirect deplibs in build tree directories where no
> direct deplib lives, will fail erroneously.

To check if I have understand this correctly:
  ~/compile/libA/..../libA.so.1
  ~/compile/libB/..../libB.so.2
  ~/compile/prog/..../prog
and
 prog -> libB.so.2
 libB.so.2 -> libA.so.1

As I understand it, calling prog will fail in this scenario. So libtool
1.5 has no real recursive dependency resolving?

How common is this scenario? When I want to test something, I install
it somewhere (and set the right -R for gcc or use LD_LIBRARY_PATH),
specially when there are dependencies. There is too much which can go
wrong if I don't do this. I don't know someone who works like described
in this scenario.

After a little bit more thinking about this: this is really a very
nasty scenario. There are a lot of foot-shooting possibilities here
even when we assume libtool does everything right. Do you really want
to support this in libtool (I can imagine that the technical solution
in libtool would be beneficial for other cases, but for this specific
example I'm surprised that you seem to want to support this)?

> For another, static linkage will not work properly, in many different
> special cases.

Let's forget about the possibility to link statically without using
libtool for a moment. Do you talk about libtool bugs (not really
recursively looking at the .la files)?

> If you can get CVS HEAD Libtool configured, you should be able to run
> its new testsuite on another libtool script; HEAD's libtool/README file
> has the details, but the invokation is something like
>   gmake check-local TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"

Ok, I try to get some time to run this for you. I assume you are
interested in the results (to the list or private mail?).

> > > > The reason is that a lot of libs (e.g. gnutls, pango, gtk, ...) also 
> > > > list 
> > > > the libs they are linked to in their pkg-config files. This is not 
> > > > necessary on systems where link_all_deplibs is set to no.  
> > > 
> > > Unless you link statically; or you cross-compile or have libraries in
> > > unusual places and do not use -rpath-link or similar.
> [...]
> 
> > Where we would get the most benefit (large packages like GNOME/KDE/...)
> > static linking doesn't really make sense. Apart from this, aren't
> > the .la files supposed to handle this recursive resolving when libtool
> > is used to link? Ok, there exist software out there which don't uses
> > libtool.
> 
> Yes.  Portably-wise, there exist systems where you have to link in all
> deplibs, direct and indirect ones, but of course that doesn't apply to
> the system in question.  IIRC (and I'm typing this from vague distant
> memories), then the FreeBSD runtime linker followed DT_RPATH entries for
> indirect deplibs, but the OpenBSD one, for example, did not.  This is
> important if, say, I have indirect deplibs in several directories below
> $HOME.

I can not find anything which explains this in the man page of our
rtld. Is this checked for in the libtool 2.0 testsuite?

> > I assume non-standard lib directories means directories which are not
> > known to ldconfig. What's the specific error case we are talking about?
> 
> Say I'm an innocent user that wants to try out one of your package
> on my system where I don't have root privileges.  That's very common.
> I can only install in directories neither the runtime linker nor the
> link editor will search by default.

That's the typical example of the use of LD_LIBRARY_PATH. I assume this
not only works without libtool, but even with libtool...

And at work I use this to install program in my shared home (I'm root
there, so I do it on purpose), if I want to use this on multiple
servers but don't want to install it on all servers (admin or devel
tools which shall not be in the official path). As I talk about Solaris
here, it's natural to specify the good runpath on the commandline of
the compiler. This was one of the first things I learned when I meet
an unix.

I fail to see how this is a bug in libtool. I can maybe agree that this
is a bug in automake/autoconf, when it doesn't set the right compiler
flags when a non-standard (lib)prefix is used, but you have to convince
me that this belongs into auto* at all, as I think they shall not know
the right flags for all compilers out there. I don't think this belongs
into libtool, as it is a generic problem, not a problem specific to
library generation.

> > Regarding cross-compiling... this is a special case, and whoever
> > cross-compiles without using the cross-compiler the right way is
> > misusing his tools and deserves an error. I can understand that you get
> > complains from users which misuse the tools, maybe you can maybe print
> > a notice/warning at configure time if the host-arch/type/os is not the
> > target-arch/type/os.
> 
> Cross-compiling really is only one setup where things may go wrong,
> and mind you, often enough Libtool is at fault here, too.

...or the person writting the configure script or Makefile.am (or even
the source).

> > > To extract settings from the libtool script, use --config, e.g.:
> > >   $LIBTOOL --config | sed -n 's/^link_all_deplibs=//p'
> > 
> > LIBTOOL is set in configure to '$(SHELL) $(top_builddir)/libtool', this
> > means it's generated by configure. At which point does it exists? After
> > calling the AC_PROG_LIBTOOL macro, or at the end when the file.in ->
> > file generation takes place? If you don't know by heart, I will make a
> > test.
> 
> Ah sorry, I misunderstood you.  Inside the configure script, you can be
> sure that the libtool script will be generated in the current directory.
> Wrt. when the script exists, things are different between CVS branch-1-5
> (1.5.x) and HEAD (2.1b):
> 
> branch-1-5: After invoking AC_PROG_LIBTOOL, the libtool script exists in
> the toplevel build directory, so you can just use ./libtool, or
>   $SHELL ./libtool
> 
> HEAD: The libtool script will only be built at the end of configure.
> If needed, you can invoke LT_OUTPUT (after LT_INIT aka. AC_PROG_LIBTOOL)
> to create it earlier.  Thus a setup portable to both versions would be:
> 
>   AC_PROG_LIBTOOL
>   m4_ifdef([LT_OUTPUT],
>   [LT_OUTPUT])
>   value=`$SHELL ./libtool --config |  sed -n 's/^link_all_deplibs=//p'`
> 
> 
> BTW, this makes me wonder a bit whether we should not rather change the
> LIBTOOL setting to '${SHELL} ${top_builddir}/libtool', that way one
> could use
>   eval $LIBTOOL ...
> 
> inside configure.

When I grep for LIBTOOL in a configure which uses libtool 1.5.22, this
is already the case.

> > > > With something like this one could do:
> > > > ---snip---
> > > > if test $deplibs_requiered != no; then
> > > >     PKGCONFIG_DEPLIBS=-lA
> > > > fi
> > > > ---snip---  
> > > 
> > > That would not work for static linking.
> > 
> > See above (.la files). Apart from that, one could at least test if
> > static libs are created or not and behave accordingly.
> 
> But at configure time, you may not know if at make time, -static may be
> used.  Of course getting --disable-shared helps.

I was talking about --disable-static here.

Bye,
Alexander.

-- 
Complex systems tend to oppose their own proper function.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137