Problematic check for run-time libs availability in autoconf scripts

[jbulow]

curl/m4/curl-functions.m4

Lines 5856 to 5876 in f157610

	dnl CURL_RUN_IFELSE
	dnl -------------------------------------------------
	dnl Wrapper macro to use instead of AC_RUN_IFELSE. It
	dnl sets LD_LIBRARY_PATH locally for this run only, from the
	dnl CURL_LIBRARY_PATH variable. It keeps the LD_LIBRARY_PATH
	dnl changes contained within this macro.
	AC_DEFUN([CURL_RUN_IFELSE], [
	case $host_os in
	darwin*)
	AC_RUN_IFELSE([AC_LANG_SOURCE([$1])], $2, $3, $4)
	;;
	*)
	old=$LD_LIBRARY_PATH
	LD_LIBRARY_PATH=$CURL_LIBRARY_PATH:$old
	export LD_LIBRARY_PATH
	AC_RUN_IFELSE([AC_LANG_SOURCE([$1])], $2, $3, $4)
	LD_LIBRARY_PATH=$old # restore
	;;
	esac
	])

When compiling a projects and its dependencies (curl) with custom compiler flags (such as enabling address sanitizers) this autoconf macro will also test that the compiler can run with the libraries found on the path(s) set in LD_LIBRARY_PATH. This will result in a failure when a library used by both the compiler and curl is used. libz is such a library.

This is how configure fails:

checking for sys/time.h... (cached) yes
checking for sys/socket.h... (cached) yes
checking for struct timeval... yes
checking run-time libs availability... failed
configure: error: one or more libs available at link-time are not available run-time. Libs used at link-time: -lpsl -lssl -lcrypto -lssl -lcrypto -lz

Looking in config.log the error is seen:

clang: symbol lookup error: /my_projects_sysroots/lib/libz.so.1: undefined symbol: __asan_option_detect_stack_use_after_return

Running from command line the problem can be reproduced by:

LD_LIBRARY_PATH=/my_projects_sysroots/lib clang
clang: symbol lookup error: /my_projects_sysroots/lib/libz.so.1: undefined symbol: __asan_option_detect_stack_use_after_return

To summarize: LD_LIBRARY_PATH should not be set when compiling conftest.c in the configure script. It should only be set when running the resulting program.

[bagder]

Problematic, yes. Also very challenging to fix, since the autotools macro AC_RUN_IFELSE that we use for this both compiles and runs the code without really offering a way to set the variable only for the execution and not for the compiling part.

[jbulow]

Maybe it is possible to temporarily change the CC variable to include the LD_LIBRARY_PATH set to $old value (from CURL_RUN_IFELSE) ?

By directly changing the configure script like this:

ac_compile='LD_LIBRARY_PATH= $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
ac_link='LD_LIBRARY_PATH= $CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'

The configure script will succeed as expected. I'm not sure if it is possible to expand $CC to include this change though.

IIRC, the compiler needs to be wrapped in a script in order for the expansion of CC to work correctly in this case.

[bagder]

Right, something like this?

diff --git a/m4/curl-functions.m4 b/m4/curl-functions.m4
index 4d4d13a40..6bef89720 100644
--- a/m4/curl-functions.m4
+++ b/m4/curl-functions.m4
@@ -5864,15 +5864,18 @@ AC_DEFUN([CURL_RUN_IFELSE], [
    case $host_os in
      darwin*)
       AC_RUN_IFELSE([AC_LANG_SOURCE([$1])], $2, $3, $4)
      ;;
      *)
+      oldcc=$CC
+      CC="./compiler $CC"
       old=$LD_LIBRARY_PATH
       LD_LIBRARY_PATH=$CURL_LIBRARY_PATH:$old
       export LD_LIBRARY_PATH
       AC_RUN_IFELSE([AC_LANG_SOURCE([$1])], $2, $3, $4)
       LD_LIBRARY_PATH=$old # restore
+      CC=$oldcc
      ;;
    esac
 ])
 
 dnl CURL_COVERAGE

and:

$ cat compiler
#!/bin/sh

LD_LIBRARY_PATH=
exec $@

[jbulow]

I think the compiler script must be generated by the configure script and set LD_LIBRARY_PATH=$old. Maybe expand $CC within the script as well to avoid having a "two part" CC variable that doesn't expand correctly in all circumstances.

I could not test the patch above as autoreconf -if ignores the files in the m4 directory when generating the configure script.

[jbulow]

A simple workaround is to use curl´s cmake buildsystem.

[bagder]

There are plenty of workarounds. If cmake is good enough, then that might be the easiest.

autoreconf -if ignores the files in the m4 directory when generating the configure script.

That's the only way we ever generate configure so that sounds wrong.

[bagder]

@jbulow does #11120 make things work for you?

[jbulow]

Yes, it seems to work fine! Sorry for the delay, I had some issues bringing the patch into our buildsystem.

Thanks!