Re: LDADD and linker options like --whole-archive

[Stefan Puiu]

Hi and thanks for replying,

On 4/19/06, Ralf Wildenhues <address@hidden> wrote:
> Hi Stefan,
> Have you ever considered using Libtool?  Its convenience archives would
> be a portable alternative to --whole-archive.

I'm not that familiar with libtool. And you have to bear in mind that
for most people in my team (which is quite big) have a hard time
grasping automake/autoconf already, so bringing in another tool might
not make them too happy.

> An alternative to --start-group/--end-group portable also to non-GNU
> binutils linkers would be to list all libraries more than once.  In
> practice, twice is often sufficient, like so: -la -lb -lc -la -lb -lc.
>  [...]

We don't need to distribute our libraries, we only distribute
binaries. So we have a certain degree of freedom in how we build those
binaries. I was using --start-group/--end-group because our project is
Linux-only, and is not that likely to become cross platform anytime
soon. Those options are definitely not be portable - at least the
Solaris linker had '-z rescan' or something like that for this
particular situation, and it applied to *all* objects on the command
line (I don't think you can do this with GNU ld). I don't remember how
it was on HP-UX.

It might be that it's a bit overkill that we're using autotools for a
project that is basically not meant to build on anything but Linux;
OK, it's C++ and we do try different gcc versions every once in a
while, but that's all.

I'm not familiar with libtool convenience libraries either, I'll look
them up. Thanks for the pointer.

> Note some things here:
> - First, you can work around the error by substituting the flags at
>   configure time, and thus hiding them from Automake
> - Second, you should do that anyway, as they are not portable,
>   and thus would better be conditionalized at configure time.

So I would use an AC_SUBST variable in configure.ac that would be set
according to platform, and in the Makefile.am I'd have something like:

<binary>_LDADD= @start_group@ <libs> @end_group@

Is my understanding correct?

>
> Note further that, if you are speaking of libraries built inside the
> project, then the preferred way of adding them is
>
>   binary_LDADD = ./libfoo.a
>
> instead of
>   binary_LDADD = -L. -lfoo
>
> because the former will get Automake to output proper dependency
> information.  (You could again use Libtool libraries instead to be
> portable to w32 hosts here, where libraries may be called libfoo.lib.)

We mostly use the first approach for our own libraries and distributed
binaries. However, I'm using the second approach for some basic test
binaries that use only limited subsets of our libraries. Of course I
could change that to the first, if you say that the dependencies would
work better.

Actually, are library dependencies supposed to work automatically?
Last time I checked they didn't, and I was using something like:

<binary>_WholeArchivePackages:= ./somedir1/libsomelib1.a \
./somedir2/libsomelib2.a ...

<binary>_RestPackages:= ./someotherdir1/libsomeotherlib1.a \
./someotherdir2/libsomeotherlib2.a ...

<binary>_Packages:= $(<binary>_WholeArchivePackages) $(<binary>_RestPackages)

<binary>_DEPENDENCIES= $(<binary>_Packages)

I agree <binary>_Packages is redundant, I might get rid of it.

>
> > Am I missing something, or is this setup as bad as it seems?
>
> No.  It's just that your flags are not portable, and Libtool would seem
> as the portable solution.  Note however that you will still have to
> either clean up your library dependency tree, or announce the
> duplication to libtool, should it not ignore it.

Would you advise something else for a build system not meant for portability?

>
> Please also note that libtool currently does not support position
> dependent linker flags such as --whole-archive, --start-group,
> --add-needed, --as-needed, or -Bstatic.  Lifting that restriction
> is planned, as possible, at some point in the future.

So if I want to use libtool, I guess I have to find the proper
dependency order for the libraries, right? Trouble is, the largest of
our binaries links in 80 libraries, so it would be quite tiresome.

I'm certainly thinking that our approach is probably not the best for
the problem. I was not involved in designing the build system, I'm
just struggling with it, and trying to learn a bit about how to get
things done properly in the process.

Stefan.