Version: 2.4.32, 2.4.33 FreeBSD 11.1, 10.3 Base OpenSSL 1.0.2, Ports OpenSSL LibreSSL 2.6.4 Base LibreSSL 2.6.4, Ports OpenSSL 1.1.0 When building Apache httpd with non-default openssl libraries, linking fails: > /usr/local/share/apr/build-1/libtool --silent --mode=link cc -O2 -fno-strict-aliasing -pipe -march=native -DLIBICONV_PLUG -fstack-protector -Wl,-rpath,/usr/local/lib -fstack-protector -L/usr/lib -L/usr/local/lib -o ab ab.lo -L/usr/local/lib -R/usr/local/lib -laprutil-1 -lexpat -L/usr/local/lib -R/usr/local/lib -lapr-1 -lcrypt -lpthread -lm -L/usr/local/lib -lssl -lcrypto -lcrypt -lpthread > ab.o: In function `main': > ab.c:(.text+0xb7f): undefined reference to `OPENSSL_init_ssl' > ab.c:(.text+0xb88): undefined reference to `OPENSSL_init_ssl' > ab.c:(.text+0xbd7): undefined reference to `SSL_CTX_set_options' > ab.c:(.text+0x1258): undefined reference to `SSL_in_init' > ab.o: In function `ssl_state_cb': > ab.c:(.text+0x2632): undefined reference to `SSL_in_init' > ab.c:(.text+0x263e): undefined reference to `SSL_is_server' > ab.o: In function `ssl_proceed_handshake': > ab.c:(.text+0x417e): undefined reference to `OPENSSL_sk_num' > ab.c:(.text+0x4196): undefined reference to `OPENSSL_sk_value' > ab.o: In function `ssl_print_cert_info': > ab.c:(.text+0x5235): undefined reference to `X509_get_version' > ab.c:(.text+0x525f): undefined reference to `X509_getm_notBefore' > ab.c:(.text+0x5290): undefined reference to `X509_getm_notAfter' > cc: error: linker command failed with exit code 1 (use -v to see invocation) This is most likely caused by a difference of order of /usr and /usr/local in CFLAGS and LDFLAGS. (Ports' headers/libs at compile time, Base headers/libs at link time). For the Apache 2.4.32 port I was preparing, I fixed this by moving EXTRA_LDFLAGS to the end in build/rules.mk > < ALL_LDFLAGS = $(MOD_LDFLAGS) $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS) > > ALL_LDFLAGS = $(MOD_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) Doesn't work for 2.4.33, will report back how I fix that.
Caused by r1823624 And by providing LDFLAGS to configure LDFLAGS: -Wl,-rpath,/usr/local/lib -fstack-protector -L/usr/lib -L/usr/local/lib Looks like I have to fix this myself
Note that the change you cited was already part of 2.4.32. Looking at the small diff between 2.4.32 and 2.4.33 I do not see anything that changes the build system. This would also not be expected. Concerning the basic problem: why do you need -L/usr/lib in LDFLAGS? Note that there are variables like ab_LDADD, MOD_SSL_LDADD etc. which can be used to make specific LDFLAGS additions for individual files with specific dependencies. Regards, Rainer
Looks like I have to fix this myself(In reply to Rainer Jung from comment #2) > Note that the change you cited was already part of 2.4.32. Looking at the > small diff between 2.4.32 and 2.4.33 I do not see anything that changes the > build system. This would also not be expected. Problem exists in both .32 and .33 > Concerning the basic problem: why do you need -L/usr/lib in LDFLAGS? I'm trying to figure out how that ends up there... I was passing --with-iconv=/usr to configure, that's now been removed Problem persists, configure keeps adding /usr/lib to EXTRA_LDFLAGS > Note that there are variables like ab_LDADD, MOD_SSL_LDADD etc. which can be > used to make specific LDFLAGS additions for individual files with specific > dependencies. I have found them, yet I was trying to find a way to fix this in the upstream code.
Look for the occurence of -L/usr/lib in the files in the build directory (after configure) in config.log (main directory, but also in srclib/ap* in case you use bundled apr/apu and in configure output. You can also attach configure output and config.log here and probably the result of grep /usr/lib build/* Regards, Rainer
Created attachment 35782 [details] Output of make -dl configure Using `script` Should capture all command output for invocation of configure
(In reply to Bernard Spil from comment #5) > Created attachment 35782 [details] > Output of make -dl configure > > Using `script` > Should capture all command output for invocation of configure And there it is... > checking for APR-util... yes > adding "-L/usr/lib" to LDFLAGS > adding "-L/usr/local/lib" to LDFLAGS
(In reply to Bernard Spil from comment #6) > (In reply to Bernard Spil from comment #5) > > Created attachment 35782 [details] > > Output of make -dl configure > > > > Using `script` > > Should capture all command output for invocation of configure > > And there it is... > > > checking for APR-util... yes > > adding "-L/usr/lib" to LDFLAGS > > adding "-L/usr/local/lib" to LDFLAGS Yes, it comes from apr-util. Ceck the output of /usr/local/bin/apu-1-config --ldflags Now, where does it come from in apr-util. Again /usr/lib is not expected there by default. So you would need to now check, how your apr-util is getting build. Regards, Rainer
(In reply to Bernard Spil from comment #5) > Created attachment 35782 [details] > Output of make -dl configure > > Using `script` > Should capture all command output for invocation of configure And there it is... > checking for APR-util... yes > adding "-L/usr/lib" to LDFLAGS > adding "-L/usr/local/lib" to LDFLAGS It was my build-env all along... APR-util was built with base OpenSSL (/usr/lib) so the httpd build framework was OK. Sorry to waste your time.
So I've solved this on one of the configs, the other one still fails. In Apache's make output I can see > configure: Configuring Apache Portable Runtime Utility library... > configure: > checking for APR-util... yes > adding "-L/usr/lib" to LDFLAGS Configure+build logs of apr+apr-util and apache here https://keg.brnrd.eu/data/111amd64-default-local/2018-03-18_15h44m04s/logs/errors/apache24-2.4.33.log https://keg.brnrd.eu/data/111amd64-default-local/2018-03-18_15h44m04s/logs/apr-1.6.3.1.6.1.log The APR-util this built provides the following output > # apu-1-config --includedir > /usr/local/include/apr-1 > # apu-1-config --ldflags > -L/usr/local/lib -L/usr/lib > # apu-1-config --libs > -lexpat > # apu-1-config --link-ld > -L/usr/local/lib -laprutil-1 > # apu-1-config --link-libtool > -L/usr/local/lib -R/usr/local/lib -laprutil-1 Even though the libraries that were built do not depend on any library in /usr/lib
I think the culprit is: --with-iconv=/usr Shouldn't things in /usr be found without explicit path flags? Could you provide the config.log file (not configure output) from the configure run for apr-util? And maybe you can try without --with-iconv=/usr. Regards, Rainer
(In reply to Rainer Jung from comment #10) > I think the culprit is: > > --with-iconv=/usr > > Shouldn't things in /usr be found without explicit path flags? > > Could you provide the config.log file (not configure output) from the > configure run for apr-util? And maybe you can try without --with-iconv=/usr. Indeed --with-iconv=/usr is causing the problem. For background: FreeBSD added iconv in the base system in 11.0. We have a 'USES= iconv' to fix this generically. For the still supported 10.3 we do need --with-iconv=${LOCALBASE}. I'll modify the port so it only adds --with-iconv on the 10.x branch. Problem solved :D Thanks for your time!
For completeness, there was an error in my comment several minutes ago... > "FreeBSD versions before 10-CURRENT on 2013-08-13 (254273) do not have a native iconv." No currently supported version of FreeBSD requires --with-iconv added to configure arguments.