You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2019/03/13 16:04:20 UTC
Significant warning of a real issue on initial ./configure ?
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.
Re: Significant warning of a real issue on initial ./configure ?
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Mar 13, 2019 at 5:58 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> $ 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
Oups, was missing this here:
$ echo $shlibpath_var
+ echo LD_LIBRARY_PATH
LD_LIBRARY_PATH
> $ ^D
Re: Significant warning of a real issue on initial ./configure ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <yl...@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 <yl...@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?
>
Re: Significant warning of a real issue on initial ./configure ?
Posted by Yann Ylavic <yl...@gmail.com>.
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 <yl...@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?
Re: Significant warning of a real issue on initial ./configure ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic <yl...@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.
Re: Significant warning of a real issue on initial ./configure ?
Posted by Yann Ylavic <yl...@gmail.com>.
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
> 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?
Also grep is possibly missing 2>/dev/null to silence ./configure a bit.
Re: Significant warning of a real issue on initial ./configure ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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.
>
>
>