Testing the theory now. On first successful invocation/creation of libtool the answer is present, the eval is not needed at all.
Subsequent ./configure invocation, same deal. In a typical linux this seems to have been a noop. I know I've seen the problem on aix or hpux or a similarly odd architecture but don't have those at hand anymore to verify. Although I *think* we can drop the eval, for safety's sake I'm leaving it behind a eval-if-empty test for the time being. If libtool sets an empty shlibpath_var value, we will still eval, still emit an error, and I'm adding a warning that the variable couldn't be determined, all harmless. And less noisy for most builders. All that remains on stderr is; rm: cannot remove 'conftest*': No such file or directory rm: cannot remove 'conftest*': No such file or directory rm: cannot remove 'libtoolT': No such file or directory Those aren't in our macros, blame them on libtool. I've silenced the debugging emit from our mkdir.sh, so that's 4 lines of noise removed from a clean vpath build. On Wed, Mar 13, 2019 at 12:16 PM Yann Ylavic <ylavic....@gmail.com> wrote: > On Wed, Mar 13, 2019 at 6:10 PM William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic <ylavic....@gmail.com> > wrote: > > > > > 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. > > If libtoolize and/or AC_PROG_LIBTOOL do the work why don't we remove > this patch/overwrite? >
