On Tue, 6 Oct 2015, Andrew Cagney wrote:
Daniel pointed out we were linking in a lot of libraries that we do not
need. Especially all the klips binaries ended up linking in nss, nspr
and gmp. Commit c32451cae7514 changes NSSLIBS and reduces this a lot.
Are you certain that it isn't still being pulled in; just indirectly?
A quick look in /proc/PID/maps will answer that.
Not for all of it, but quite a bunch of klips tools really don't need
any NSS and I'm pretty sure those not dragging it in.
I still see linking happening against libsmime3 and libssl3, which I
don't understand. We do not specifically specify these, so they must
come in via libnss3 or libnspr4. I am not sure if they can be prevented
or how to prevent it. Maybe Andrew can have a look at this.
Last time I looked, based on this hack:
for f in -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl
-lpthread -lcap-ng-lrt -lunbound -levent -levent_pthreads -lcurl
-lpthread -lcrypt -lpam -ldl -lnss3 -lnssutil3 -lplds4 -lplc4
-lnspr4 -lpthread -ldl -lgmp ; do echo $f ; done | sort -u | sed -e
's;-l;/usr/lib64/lib;' -e 's/$/.so/' | while read l ; do ldd $l 2>&1 |
grep ssl3 > /dev/null && echo $l ; done
I found ssl was being pulled in via [lib]curl (I also remember
something about the libcurl dependency being removed?).
Yeah we thought we wouldn't need it directly, but then Matt needed to
use it for CRL requests, so it is back. Some of this lives in
lib/libswan so we end up dragging in some things that some of our
tools really don't need (like libcurl dependancies just because we
handle secrets)
So more work can surely be done to minimize this further. Now, I assume
on a real machine both openssl and nss are already loading in the system
anyway, so from a practical point of view, it might matter little.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
