[fedfs-utils] [PATCH] build: fix gcc linker library argument placement

[David Disseldorp]

Hi Chuck,

On Wed, 12 Jun 2013 09:28:07 -0700 (PDT)
Chuck Lever <chuck.lever at oracle.com> wrote:

> Hi David-
> 
> Your patch is under review.  See:
> 
>   http://patchwork.ozlabs.org/project/fedfs-utils/list/
> 
> I'm happy to see OpenSuSE consider packaging fedfs-utils.
> 
> 
> I build fedfs-utils all the time on Fedora 18 with gcc 4.7.2 without this patch, and I spent some effort setting up the order of the libraries in the Makefiles.
> 
> I'm not sure I buy your patch description's explanation of the problem.  Can you elaborate?  Was there a point in the past when fedfs-utils could build on openSuSE?  Is there some other tool chain issue that might cause your issue?  Was there a change with gcc 4.7.3 that broke something?
> 
> A reference to the GNU autotools or automake documentation that recommends library ordering might also be good.  I'm looking for some help understanding the issue.
> 

This is the first time I've attempted to build fedfs-utils on openSUSE.
Without the patch, I run into the following failure at link time:
[   25s] libtool: link: gcc -std=gnu99 -ggdb -fstrict-aliasing -fPIE -Wall -Wextra -pedantic -Wformat=2 -Wstrict-aliasing=2 -Wp,-D_FORTIFY_SOURCE=2 -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -o fedfs-set-nsdb-params fedfs-set-nsdb-params.o  -ltirpc -lldap -llber /usr/lib64/libxml2.so -ldl -lz -llzma -lm -lsqlite3 -lidn -luuid -lcrypto -lssl ../../src/libadmin/.libs/libadmin.a ../../src/libjunction/.libs/libjunction.a ../../src/libnsdb/.libs/libnsdb.a ../../src/libxlog/.libs/libxlog.a -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64
[   25s] ../../src/libnsdb/.libs/libnsdb.a(connsec.o): In function `nsdb_connsec_crypto_startup':
[   25s] /home/abuild/rpmbuild/BUILD/fedfs-utils-0.9.1/src/libnsdb/connsec.c:47: undefined reference to `CRYPTO_set_mem_functions'
...

The CRYPTO_set_mem_functions symbol is required by libnsdb.a and
provided by libcrypto.so. With -lcrypto specified before libnsdb.a in
the argument list, gcc fails to locate the CRYPTO_set_mem_functions
symbol.
IIUC, this behaviour is in-line with the documentation:
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

The command succeeds if the arguments are reordered such that the static
libraries appear before the shared object arguments.

I'm curious as to why you don't see the same issue. How is gcc invoked
when linking fedfs-set-nsdb-params in your case?

Cheers, David