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

[Chuck Lever]

Hi David-

On Jun 14, 2013, at 12:46 PM, Chuck Lever <chuck.lever at oracle.com> wrote:

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

I've tried to reproduce your problem on Fedora.  I have not been successful.

This page:

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


suggests that the use of noinst_LTLIBRARIES in the Makefiles should prevent libtool from setting "-rpath" on the linker command line.  Since fedfs-utils already uses noinst_LTLIBRARIES, I can't figure out why your build would have that linker option present.

I've tried explicitly setting the options you have: "-Wl,-rpath -Wl,/usr/lib64" and my build still works fine.

In the meantime, I've applied your patch in my private repo, and it doesn't break my build, thus it passes the documented acceptance tests.  But I'm not satisfied that we understand yet what is broken for you.

For the time being, I'll let you continue to troubleshoot this, and will leave your patch uncommitted.  Let me know of any progress.

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