I think this comes from;
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
# get libtool's setting of shlibpath_var
eval `grep "^shlibpath_var=[[A-Z_]]*$" $apr_builddir/libtool`
if test "x$shlibpath_var" = "x"; then
shlibpath_var=REPLACE_WITH_YOUR_SHLIBPATH_VAR
fi
The assignment of shlibpath_var within an eval isn't promoted into the
current env table, right? This code following AC_PROG_LIBTOOL appears to be
a no--op unless I'm missing something obvious.
On Wed, Mar 13, 2019 at 11:04 AM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> First pass;
>
> rm: cannot remove 'conftest*': No such file or directory
> rm: cannot remove 'conftest*': No such file or directory
> grep: /home/wrowe/dev/build/apr2-ossl111/libtool: No such file or directory
>
> We cause that last step in configure.in of apr. During a first
> ./configure in a vpath build, there is no libtool script yet to inspect.
>
> ./config.status:hardcode_shlibpath_var='unsupported'
> ./config.status:shlibpath_var='LD_LIBRARY_PATH'
> ./config.status:S["shlibpath_var"]="LD_LIBRARY_PATH"
> ./config.status:shlibpath_var=$shlibpath_var
> ./config.status:# "absolute",i.e impossible to change by setting
> \$shlibpath_var if the
> ./config.status:hardcode_shlibpath_var=$hardcode_shlibpath_var
> ./config.log:shlibpath_var='LD_LIBRARY_PATH'
>
> Second pass;
>
> rm: cannot remove 'conftest*': No such file or directory
> rm: cannot remove 'conftest*': No such file or directory
>
> Same config.status values *on linux*.
>
> I'm concerned that the same values would not be present on aix, hpux, or
> any other oddballs which don't follow the LD_LIBRARY_PATH convention shown
> above - as this is also the fallback logic, and that the first-pass error
> indicates a critical flaw in a clean vpath ./configure vs any
> re-./configure pass.
>
>
>
