On Jun 13, 2013, at 5:20 AM, David Disseldorp <[email protected]> wrote:
> Hi Chuck, > > On Wed, 12 Jun 2013 09:28:07 -0700 (PDT) > Chuck Lever <[email protected]> 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 _______________________________________________ fedfs-utils-devel mailing list [email protected] https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel
