Noticed a couple packages failing after the openssl bump (http://git.buildroot.net/buildroot/commit/?id=757690a262fa050ee18847ecee02672f16383b49) netsnmp (arm build) .... "checking for authentication support... configure: error: Asked to use OpenSSL but I couldn't find it." ... wpa_supplicant (ppc build) .... LD wpa_cli CC ../src/crypto/crypto_openssl.c /accts/mlweber1/proj/br-continuous/cfgs/30-fis-x86-glibc-ext/host/usr/i686-buildroot-linux-gnu/sysroot/usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x21): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x37): undefined reference to `dlsym' ... I've attached configs to reproduce and error logs. I won't get a chance to investigate these for ~week, but should have some time to test if someone beats me to a fix :-)
Created attachment 5168 [details] defconfigs and build logs
Tried a simple i386/i586 sourcery 2012.09 + ARM A9 EABI linaro 2013.11 target with openssl + wpa_supplicant + netsnmp enabled without issues. And i'm not seeing any failure in the autobuilders either. And i've personally built for uClibc toolchains with e300c3 & e500v2 targets without issues either (which include netsnmp, wpa_supplicant and other packages that use openssl). So i can't get a failure scenario. Sure there's nothing else going on? (specially since you're using your own toolchains) and the problem lies somewhere else?
I'm wondering if what I'm seeing is ccache related. I'll clear out my cache and rebuild to night and see where things stand. Everything had built find up to that openssl bump and that bump wasn't a major set of changes is what confused me. Sorry should have tried clearing the cash before posting the bug. Didn't think it could just stale cached objs. I'll tomorrow with results/clarification of the issue.
It looks like it's ccache related, below is output from the build of openssl. It wasn't creating libcrypto.so, which would explain netsnmp and wpa_supplicant failing. I would add ccache to your test build and that should reproduce it. This was caught by our nightly builder, I think the only difference between the autobuilder builds and what we do, is that we use ccache (So that might explain why it didn't catch it). make[5]: Entering directory `/accts/mlweber1/proj/br-continuous/cfgs/10-omap-arm-eglibc-ext/build/openssl-1.0.1f' /accts/mlweber1/proj/br-continuous/cfgs/10-omap-arm-eglibc-ext/host/usr/bin/ccache: invalid option -- 'f' Usage: ccache [options] ccache compiler [compiler options] compiler [compiler options] (via symbolic link) Options: -c, --cleanup delete old files and recalculate size counters (normally not needed as this is done automatically) -C, --clear clear the cache completely -F, --max-files=N set maximum number of files in cache to N (use 0 for no limit) -M, --max-size=SIZE set maximum size of cache to SIZE (use 0 for no limit; available suffixes: G, M and K; default suffix: G) -s, --show-stats show statistics summary -z, --zero-stats zero statistics counters -h, --help print this help text -V, --version print version and copyright information See also <http://ccache.samba.org>. make[5]: *** [link_a.gnu] Error 1 make[5]: Leaving directory `/accts/mlweber1/proj/br-continuous/cfgs/10-omap-arm-eglibc-ext/build/openssl-1.0.1f' make[4]: *** [do_linux-shared] Error 2 make[4]: Leaving directory `/accts/mlweber1/proj/br-continuous/cfgs/10-omap-arm-eglibc-ext/build/openssl-1.0.1f' make[4]: Entering directory `/accts/mlweber1/proj/br-continuous/cfgs/10-omap-arm-eglibc-ext/build/openssl-1.0.1f'
Patch sent to the BR list and rt@openssl.org
Patch sent by Gustavo has been accepted now. Problem solved.