Re: Linking userland with lld
On Sat, Jan 21, 2017 at 10:58:59AM +0100, Mark Kettenis wrote: > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our > ancient binutils we don't notice this, because we link against libtls, > which as a DT_NEEDED entry for libcrypto. But lld doesn't fall for > this. And I believe modern binutils don't do this either. Yes, GNU decided at some point that you are only supposed to use symbols from a library you also have a DT_NEEDED entry for. Of course, the dynamic linker doesn't know that, so the link time view doesn't necessarily reflect what the runtime linker is doing. I still have on my TODO list to fix lld, so that the behavior at least is optional. Joerg
Re: Linking userland with lld
> The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3 > binutils. Mostly works, but it triggers an issue in building ldapd > and ldapctl. > > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our > ancient binutils we don't notice this, because we link against libtls, > which as a DT_NEEDED entry for libcrypto. But lld doesn't fall for > this. And I believe modern binutils don't do this either. This also prevents them from building in cross-bin, FWIW.
Re: Linking userland with lld
I stole your diff yesterday, when I built a static snapshot for fun.
> The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3
> binutils. Mostly works, but it triggers an issue in building ldapd
> and ldapctl.
>
> The problem here is that the code uses the SHA1 functions in
> libcrypto, but doesn't explicitly link against that library. With our
> ancient binutils we don't notice this, because we link against libtls,
> which as a DT_NEEDED entry for libcrypto. But lld doesn't fall for
> this. And I believe modern binutils don't do this either.
>
> Diff below fixes this (and trims ${LIBSSL} from DPADD since we don't
> link against that).
>
> ok?
>
>
> Index: ldapd/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/ldapd/Makefile,v
> retrieving revision 1.13
> diff -u -p -r1.13 Makefile
> --- ldapd/Makefile1 May 2016 00:32:37 - 1.13
> +++ ldapd/Makefile21 Jan 2017 09:50:35 -
> @@ -8,8 +8,8 @@ SRCS= ber.c log.c control.c \
> auth.c modify.c index.c evbuffer_tls.c \
> validate.c uuid.c schema.c imsgev.c syntax.c matching.c
>
> -LDADD= -ltls -levent -lz -lutil
> -DPADD= ${LIBEVENT} ${LIBTLS} ${LIBCRYPTO} ${LIBSSL} ${LIBZ}
> ${LIBUTIL}
> +LDADD= -ltls -lcrypto -levent -lz -lutil
> +DPADD= ${LIBTLS} ${LIBCRYPTO} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
> CFLAGS+= -I${.CURDIR} -g
> CFLAGS+= -Wall -Wstrict-prototypes -Wmissing-prototypes
> CFLAGS+= -Wmissing-declarations
> Index: ldapctl/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/ldapctl/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- ldapctl/Makefile 1 May 2016 10:40:27 - 1.6
> +++ ldapctl/Makefile 21 Jan 2017 09:50:35 -
> @@ -7,8 +7,8 @@ MAN= ldapctl.8
> SRCS=ldapctl.c parse.y btree.c log.c ber.c util.c \
> index.c attributes.c schema.c syntax.c matching.c
>
> -LDADD= -ltls -levent -lz -lutil
> -DPADD= ${LIBTLS} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
> +LDADD= -ltls -lcrypto -levent -lz -lutil
> +DPADD= ${LIBTLS} ${LIBCRYPTO} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
> CFLAGS+= -I${.CURDIR}/../ldapd
> CFLAGS+= -Wall -Wstrict-prototypes -Wmissing-prototypes
> CFLAGS+= -Wmissing-declarations
>
Linking userland with lld
The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3
binutils. Mostly works, but it triggers an issue in building ldapd
and ldapctl.
The problem here is that the code uses the SHA1 functions in
libcrypto, but doesn't explicitly link against that library. With our
ancient binutils we don't notice this, because we link against libtls,
which as a DT_NEEDED entry for libcrypto. But lld doesn't fall for
this. And I believe modern binutils don't do this either.
Diff below fixes this (and trims ${LIBSSL} from DPADD since we don't
link against that).
ok?
Index: ldapd/Makefile
===
RCS file: /cvs/src/usr.sbin/ldapd/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- ldapd/Makefile 1 May 2016 00:32:37 - 1.13
+++ ldapd/Makefile 21 Jan 2017 09:50:35 -
@@ -8,8 +8,8 @@ SRCS= ber.c log.c control.c \
auth.c modify.c index.c evbuffer_tls.c \
validate.c uuid.c schema.c imsgev.c syntax.c matching.c
-LDADD= -ltls -levent -lz -lutil
-DPADD= ${LIBEVENT} ${LIBTLS} ${LIBCRYPTO} ${LIBSSL} ${LIBZ} ${LIBUTIL}
+LDADD= -ltls -lcrypto -levent -lz -lutil
+DPADD= ${LIBTLS} ${LIBCRYPTO} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
CFLAGS+= -I${.CURDIR} -g
CFLAGS+= -Wall -Wstrict-prototypes -Wmissing-prototypes
CFLAGS+= -Wmissing-declarations
Index: ldapctl/Makefile
===
RCS file: /cvs/src/usr.sbin/ldapctl/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- ldapctl/Makefile1 May 2016 10:40:27 - 1.6
+++ ldapctl/Makefile21 Jan 2017 09:50:35 -
@@ -7,8 +7,8 @@ MAN=ldapctl.8
SRCS= ldapctl.c parse.y btree.c log.c ber.c util.c \
index.c attributes.c schema.c syntax.c matching.c
-LDADD= -ltls -levent -lz -lutil
-DPADD= ${LIBTLS} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
+LDADD= -ltls -lcrypto -levent -lz -lutil
+DPADD= ${LIBTLS} ${LIBCRYPTO} ${LIBEVENT} ${LIBZ} ${LIBUTIL}
CFLAGS+= -I${.CURDIR}/../ldapd
CFLAGS+= -Wall -Wstrict-prototypes -Wmissing-prototypes
CFLAGS+= -Wmissing-declarations
