Re: link_all_deplibs feature

[Ralf Wildenhues]

* 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.

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

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"

> > > Can someone please explain me what the right thing to do in the
> > > following patch and what is superflous before I send it to
> > > address@hidden  
> > 
> > Have a look at the Debian diff against GNU Libtool (I can dig out a URL
> > for it if you like).
> 
> You mean http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch ?

I believe that's the important bits.  Otherwise,
<http://packages.debian.org/etch/libtool> has a link to the .diff.gz on
the right hand side.

> > > 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 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.

> 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.

> > 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.

> > > 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.

> Do you have an idea how relevant static linking for complex software
> (where there are more than one level of library dependencies) is
> nowadays (except for embedded systems, where a lot is done by hand
> anyway)?

It's used in scientific libraries, or where one does not want to rebuild
for several systems (yes, I know there are issues with that, too).

Cheers,
Ralf