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@xxxxxxx> > > 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
