On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic <[email protected]> wrote:
> On Wed, Mar 13, 2019 at 5:20 PM William A Rowe Jr <[email protected]> > wrote: > > > > 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? > > Hmm, should be working: > > $ sh -x > $ eval `grep '^shlibpath_var=[A-Z_]*$' ./libtool` > + grep ^shlibpath_var=[A-Z_]*$ ./libtool > + eval shlibpath_var=LD_LIBRARY_PATH > + shlibpath_var=LD_LIBRARY_PATH > $ ^D > and then ... sh-4.4$ echo $shlibpath_var + echo LD_LIBRARY_PATH LD_LIBRARY_PATH Looks that the eval assignment is preserved, my bash was telling me otherwise. > > This code following AC_PROG_LIBTOOL appears to be a no--op unless I'm missing something obvious. > The grep-ed double square brackets look weird to me, does not work > with my (ba)sh at least, so doesn't it enter the > REPLACE_WITH_YOUR_SHLIBPATH_VAR path anytime? I don't think we hit it because we have shlibpath_var previously assigned in our shell, from the libtoolize steps earlier? > Also grep is possibly missing 2>/dev/null to silence ./configure a bit. Provided we've picked up shlibpath_var value from the earlier AC_PROG_LIBTOOL macro but before ./libtool is written and we attempt this eval step, then I guess all is well and we can mute that.
