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

[Chuck Lever]

On Jun 13, 2013, at 5:20 AM, David Disseldorp <ddiss at suse.de> wrote:

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

Good question.

I pasted output from "make" on my system, and added extra line breaks for clarity.

$ ./autogen.sh
$ ./configure --exec=/usr
$ make

  ...

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I. -I../../src/include -I/usr/include/tirpc  -ggdb -fstrict-aliasing -fPIE -Wall -Wextra -pedantic -Wformat=2 -Wstrict-aliasing=2 -Wp,-D_FORTIFY_SOURCE=2 -g -O2 -MT fedfs-set-nsdb-params.o -MD -MP -MF .deps/fedfs-set-nsdb-params.Tpo -c -o fedfs-set-nsdb-params.o fedfs-set-nsdb-params.c

mv -f .deps/fedfs-set-nsdb-params.Tpo .deps/fedfs-set-nsdb-params.Po

/bin/sh ../../libtool  --tag=CC   --mode=link gcc -std=gnu99 -ggdb -fstrict-aliasing -fPIE -Wall -Wextra -pedantic -Wformat=2 -Wstrict-aliasing=2 -Wp,-D_FORTIFY_SOURCE=2 -g -O2   -o fedfs-set-nsdb-params fedfs-set-nsdb-params.o -ltirpc -lldap -llber -lxml2 -lsqlite3 -lidn -luuid -lcrypto -lssl ../../src/libadmin/libadmin.la ../../src/libjunction/libjunction.la ../../src/libnsdb/libnsdb.la ../../src/libxlog/libxlog.la 

libtool: link: gcc -std=gnu99 -ggdb -fstrict-aliasing -fPIE -Wall -Wextra -pedantic -Wformat=2 -Wstrict-aliasing=2 -Wp,-D_FORTIFY_SOURCE=2 -g -O2 -o fedfs-set-nsdb-params fedfs-set-nsdb-params.o  -ltirpc -lldap -llber -lxml2 -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

  ...

And for reference:

$ nm src/libnsdb/.libs/libnsdb.a | grep CRYPTO
                 U CRYPTO_cleanup_all_ex_data
                 U CRYPTO_set_mem_functions

You are passing "-Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64" to the linker.  I suspect the "-rpath" option is the problem.  See:

  http://www.gnu.org/software/libtool/manual/html_node/Static-libraries.html

This is how my build creates libnsdb.a:

/bin/sh ../../libtool  --tag=CC   --mode=link gcc -std=gnu99 -ggdb -fstrict-aliasing -fPIC -Wall -Wextra -pedantic -Wformat=2 -Wstrict-aliasing=2 -Wp,-D_FORTIFY_SOURCE=2 -g -O2   -o libnsdb.la  administrator.lo annotation.lo connsec.lo display.lo fileserver.lo ldap.lo nsdb.lo path.lo sqlite.lo

libtool: link: ar cru .libs/libnsdb.a .libs/administrator.o .libs/annotation.o .libs/connsec.o .libs/display.o .libs/fileserver.o .libs/ldap.o .libs/nsdb.o .libs/path.o .libs/sqlite.o 

libtool: link: ranlib .libs/libnsdb.a

libtool: link: ( cd ".libs" && rm -f "libnsdb.la" && ln -s "../libnsdb.la" "libnsdb.la" )

My uneducated guess: you can probably get fedfs-utils 0.9 to build on OpenSuSE by figuring out how to stop automake from adding the "-rpath" option on the linker command line.  Give this a try and let me know what happens.

If there is a bug in fedfs-utils, it's probably that the fedfs-utils build should create convenience libraries rather than legacy object archives, maybe?  I hesitate to consider that kind of change for 0.9.y, but it would probably be a good thing to do in 0.10.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com