Re: [PATCH] xfsprogs: fix static build problems caused by liburcu

["Theodore Ts'o" <tytso@mit.edu>]

On Sat, Jan 08, 2022 at 03:23:38PM -0800, Darrick J. Wong wrote:
> On Sat, Jan 08, 2022 at 02:57:39PM -0500, Theodore Ts'o wrote:
> > The liburcu library has a dependency on pthreads.  Hence, in order for
> > static builds of xfsprogs to work, $(LIBPTHREAD) needs to appear
> > *after* $(LUBURCU) in LLDLIBS.  Otherwise, static links of xfs_* will
> > fail due to undefined references of pthread_create, pthread_exit,
> > et. al.
> > 
> > Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 
> Ugh, I keep forgetting that ld wants library dependencies in reverse
> order nowadays...

Actually, for static linking this has always been the case.  For
example if foo_init() in libfoo calls bar_init() from libbar, you have
to specify the order as "-lfoo -lbar".  That's because the static
linker processes the libraries once, in command-line order.  So when
the program uses (and thus pulls in foo_init), the linker searches
-lfoo to find foo_init, and then looks at what symbols it needs, and
then will start searching the rest of the libraries to find bar_init,
which it will find only if -lbar is specified after -lfoo.

The problem is we've gotten spoiled by ELF shared libraries, where the
symbols are resolved as they are needed, so when main() calls
foo_init() at runtime, only then will the shared linker look for
bar_init(), which it will find regardless of wheter the libraries are
specified as "-lfoo -lbar" or "-lbar -lfoo".

So in general, libraries which are used by other libraries, but which
have no dependenciees of their own, should be listed last.  This
includes libraries such as -lpthread, -lsocket on Solaris, -lnsl (if
you use NIS/Yellow Pages), etc. --- but you'll only notice if you try
static linking.

Cheers,

					- Ted