On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic <ylavic....@gmail.com> wrote:

> On Wed, Mar 13, 2019 at 5:20 PM William A Rowe Jr <wr...@rowe-clan.net>
> 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.

Reply via email to