Libtool breaks linking order

[Guillaume Rousse]

Hello list.

When building nfs-utils, I have a strange linking order issue with
libtool (2.2.6b).

The makefile.am reads:
gssd_LDADD =../../support/nfs/libnfs.a \
  $(RPCSECGSS_LIBS) $(GSSGLUE_LIBS) $(KRBLIBS)

(Full file available at
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/Makefile.am;h=95a2bd0f8c6cc21247d71549680b04a52f01772e;hb=HEAD)

Note than $(GSSGLUE_LIBS) appears before $(KRBLIBS).

With the following values:
GSSGLUE_LIBS = -lgssglue -ldl
KRBLIBS = -L/usr/lib64 -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fstack-protector-all -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv
-ldl

libtool is invocated correctly:
/bin/sh ../../libtool --tag=CC   --mode=link gcc -Wall
-Wstrict-prototypes  -pipe -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fstack-protector-all  -I/usr/include/gssglue    -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -fstack-protector-all  -Wl,--as-needed
-Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -o svcgssd svcgssd-context.o
svcgssd-context_mit.o svcgssd-context_heimdal.o svcgssd-context_lucid.o
svcgssd-context_spkm3.o svcgssd-gss_util.o svcgssd-gss_oids.o
svcgssd-err_util.o svcgssd-svcgssd.o svcgssd-svcgssd_main_loop.o
svcgssd-svcgssd_mech2file.o svcgssd-svcgssd_proc.o
../../support/nfs/libnfs.a  -lgssglue -ldl   -lnfsidmap -L/usr/lib64 -O2
-g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -ltirpc

Note than -lgssglue comes before -lgssapi_krb5.

However, libtool changes this to
libtool: link: gcc -Wall -Wstrict-prototypes -pipe -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -fstack-protector-all -I/usr/include/gssglue
-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all
-Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-O1 -o svcgssd
svcgssd-context.o svcgssd-context_mit.o svcgssd-context_heimdal.o
svcgssd-context_lucid.o svcgssd-context_spkm3.o svcgssd-gss_util.o
svcgssd-gss_oids.o svcgssd-err_util.o svcgssd-svcgssd.o
svcgssd-svcgssd_main_loop.o svcgssd-svcgssd_mech2file.o
svcgssd-svcgssd_proc.o -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fstack-protector-all ../../support/nfs/libnfs.a
/usr/lib64/libnfsidmap.so -L/usr/lib64 -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -lresolv /usr/lib64/libtirpc.so -lnsl /usr/lib64/libgssglue.so
-ldl -lpthread

Note than -lgssglue has been turned into /usr/lib64/libgssglue.so, and
moved after -lgssapi_krb5, which wasn't modified. From --debug output
(attached), this behaviour difference seems to be caused the the
presence of a .la file for libgssglue.so, and not for libgssapi_krb5.

All in all, it breaks resulting binary, because libgssglue should be
linked before libgssapi_krb5, as both contains the same symbol with
incompatible ABI, and only the one from libgssglue should be used.

See this discussion for details:
http://linux-nfs.org/pipermail/nfsv4/2010-March/012201.html

-- 
BOFH excuse #42:

spaghetti cable cause packet failure

libtool.output
Description: Text document

smime.p7s
Description: S/MIME Cryptographic Signature