Re: Libtool breaks linking order

[Ralf Wildenhues]

Hello Guillaume,

* Guillaume Rousse wrote on Mon, Mar 29, 2010 at 03:00:01PM CEST:
> 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

The problem comes from /usr/lib64/libtirpc.la
It lists gssglue as deplib.

If you were linking statically, then it might be necessary to list
libgssglue.a after libtirp.a.  This is what libtool can know from the
.la files, and the reason for libtool to list gssglue after libtirp.  It
cannot know from the .la files that you are playing dirty unportable (to
non-ELF systems) tricks with symbols in gssglue overriding symbols from
gssapi_krb5.

One workaround would be to (temporarily) remove /usr/lib64/libtirpc.la.
Another one would be to add libgssapi_krb5 to the deplibs of libtirpc
(but I don't know how well that fits the model of these libraries).

Hope that helps.

Cheers,
Ralf