You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Julian Foad <ju...@apache.org> on 2018/02/26 17:39:32 UTC
APR's check for installed libtool is inconsistent
(CC'ing Subversion as Subversion's build system both uses and kind-of
duplicates this.)
APR's 'build/buildcheck.sh' says:
[[[
# Require libtool 1.4 or newer
libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
...
]]]
and fails if it doesn't find a 'libtool' binary at version >= 1.4;
but 'buildconf' says:
[[[
build/buildcheck.sh $verbose || exit 1
libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
libtoolize14 libtoolize`
]]]
Different tool name, different order of checking for versions of it.
This difference caused a problem on my Ubuntu 16.04 system, where only
the main 'libtool' package was installed which provides only a
'libtoolize' binary, and the optional 'libtool-bin' package which adds a
'libtool' binary was not installed. I was able to install the latter to
work around this issue.
Looks like it should be changed to be consistent. What do you think?
- Julian
Re: APR's check for installed libtool is inconsistent
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> Branko Čibej wrote (to dev@subversion.a.o):
>> On 26.02.2018 18:39, Julian Foad wrote:
>>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>>> duplicates this.)
>>>
>>> APR's 'build/buildcheck.sh' says:
>>> [[[
>>> # Require libtool 1.4 or newer
>>> libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
>>> ...
>>> ]]]
>>>
>>> and fails if it doesn't find a 'libtool' binary at version >= 1.4;
>>>
>>> but 'buildconf' says:
>>> [[[
>>> build/buildcheck.sh $verbose || exit 1
>>>
>>> libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
>>> libtoolize14 libtoolize`
>>> ]]]
>>>
>>> Different tool name, different order of checking for versions of it.
>>>
>>> This difference caused a problem on my Ubuntu 16.04 system, where only
>>> the main 'libtool' package was installed which provides only a
>>> 'libtoolize' binary, and the optional 'libtool-bin' package which adds
>>> a 'libtool' binary was not installed. I was able to install the latter
>>> to work around this issue.
>>
>> FWIW, Subversion's autogen.sh and build/buildcheck.sh only look for
>> 'libtoolize' in one of its aliased names, it doesn't look for 'libtool'
>> at all, since about 3 years ago.
>>
>>> Looks like it should be changed to be consistent. What do you think?
>>
>> +1 to duplicating Subversion's logic for finding libtoolize in APR.
>
> Subversion's 'autogen.sh' says:
> [[[
> # Much like APR except we do not prefer libtool 1 over libtool 2.
> libtoolize="`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`"
> ]]]
>
> Subversion's 'build/buildcheck.sh' says:
> [[[
> # Much like APR except we do not prefer libtool 1 over libtool 2.
> libtoolize=${LIBTOOLIZE:-`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`}
> ]]]
>
> In addition, my colleague Michael reports Subversion's 'autogen.sh'
> does not find the 'aclocal' and 'libtool' directories on CentOS 7.
On CentOS 7:
# ./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14
/bin/libtoolize
so this part doesn't work:
ltpath="`dirname $libtoolize`" # /bin
if [ -d "$ltpath/../share/aclocal/." ] # looks for /share/aclocal/.
whereas if we searched for a path to 'aclocal' executable instead, we might
have better 'luck' with that '../share' technique:
# readlink -f /usr/bin/aclocal
/usr/bin/aclocal
# readlink -f /bin/aclocal
/usr/bin/aclocal
Not saying we should, just an observation.
APR's 'buildconf' contains some similar logic:
ltpath=`dirname $libtoolize`
ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
although not as its main code path.
> A patch equivalent to this one works:
>
> [[[
> Index: autogen.sh
> ===================================================================
> --- autogen.sh (revision 1825663)
> +++ autogen.sh (working copy)
> @@ -81,6 +81,8 @@ if [ "x$LIBTOOL_M4" = "x" ]; then
> ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
> if [ -d "$ltpath/../share/aclocal/." ]; then
> ltm4=`cd "$ltpath/../share/aclocal" && pwd`
> + elif [[ $(readlink -f $(which aclocal)) == "/usr/bin/aclocal" ]]; then
> + ltm4='/usr/share/aclocal'
> else
> echo "Libtool helper path not found $ltm4_error"
> echo " expected at: '$ltpath/../share/aclocal'"
> @@ -129,6 +131,8 @@ if [ $lt_major_version -ge 2 ]; then
> ltconfig=`cd "$ltpath/../share/libtool/config" && pwd`
> elif [ -d "$ltpath/../share/libtool/build-aux/." ]; then
> ltconfig=`cd "$ltpath/../share/libtool/build-aux" && pwd`
> + elif [[ $(readlink -f $(which libtool)) == "/usr/bin/libtool" ]]; then
> + ltconfig='/usr/share/libtool/config'
> else
> echo "Autoconf helper path not found $ltconfig_error"
> echo " expected at: '$ltpath/../share/libtool/config'"
> ]]]
>
> (Beware Bash-isms.)
>
> It looks to me like this could/should be more general. Anybody care to
> suggest how?
- Julian
Re: APR's check for installed libtool is inconsistent
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> Branko Čibej wrote (to dev@subversion.a.o):
>> On 26.02.2018 18:39, Julian Foad wrote:
>>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>>> duplicates this.)
>>>
>>> APR's 'build/buildcheck.sh' says:
>>> [[[
>>> # Require libtool 1.4 or newer
>>> libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
>>> ...
>>> ]]]
>>>
>>> and fails if it doesn't find a 'libtool' binary at version >= 1.4;
>>>
>>> but 'buildconf' says:
>>> [[[
>>> build/buildcheck.sh $verbose || exit 1
>>>
>>> libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
>>> libtoolize14 libtoolize`
>>> ]]]
>>>
>>> Different tool name, different order of checking for versions of it.
>>>
>>> This difference caused a problem on my Ubuntu 16.04 system, where only
>>> the main 'libtool' package was installed which provides only a
>>> 'libtoolize' binary, and the optional 'libtool-bin' package which adds
>>> a 'libtool' binary was not installed. I was able to install the latter
>>> to work around this issue.
>>
>> FWIW, Subversion's autogen.sh and build/buildcheck.sh only look for
>> 'libtoolize' in one of its aliased names, it doesn't look for 'libtool'
>> at all, since about 3 years ago.
>>
>>> Looks like it should be changed to be consistent. What do you think?
>>
>> +1 to duplicating Subversion's logic for finding libtoolize in APR.
>
> Subversion's 'autogen.sh' says:
> [[[
> # Much like APR except we do not prefer libtool 1 over libtool 2.
> libtoolize="`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`"
> ]]]
>
> Subversion's 'build/buildcheck.sh' says:
> [[[
> # Much like APR except we do not prefer libtool 1 over libtool 2.
> libtoolize=${LIBTOOLIZE:-`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`}
> ]]]
>
> In addition, my colleague Michael reports Subversion's 'autogen.sh'
> does not find the 'aclocal' and 'libtool' directories on CentOS 7.
On CentOS 7:
# ./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14
/bin/libtoolize
so this part doesn't work:
ltpath="`dirname $libtoolize`" # /bin
if [ -d "$ltpath/../share/aclocal/." ] # looks for /share/aclocal/.
whereas if we searched for a path to 'aclocal' executable instead, we might
have better 'luck' with that '../share' technique:
# readlink -f /usr/bin/aclocal
/usr/bin/aclocal
# readlink -f /bin/aclocal
/usr/bin/aclocal
Not saying we should, just an observation.
APR's 'buildconf' contains some similar logic:
ltpath=`dirname $libtoolize`
ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
although not as its main code path.
> A patch equivalent to this one works:
>
> [[[
> Index: autogen.sh
> ===================================================================
> --- autogen.sh (revision 1825663)
> +++ autogen.sh (working copy)
> @@ -81,6 +81,8 @@ if [ "x$LIBTOOL_M4" = "x" ]; then
> ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
> if [ -d "$ltpath/../share/aclocal/." ]; then
> ltm4=`cd "$ltpath/../share/aclocal" && pwd`
> + elif [[ $(readlink -f $(which aclocal)) == "/usr/bin/aclocal" ]]; then
> + ltm4='/usr/share/aclocal'
> else
> echo "Libtool helper path not found $ltm4_error"
> echo " expected at: '$ltpath/../share/aclocal'"
> @@ -129,6 +131,8 @@ if [ $lt_major_version -ge 2 ]; then
> ltconfig=`cd "$ltpath/../share/libtool/config" && pwd`
> elif [ -d "$ltpath/../share/libtool/build-aux/." ]; then
> ltconfig=`cd "$ltpath/../share/libtool/build-aux" && pwd`
> + elif [[ $(readlink -f $(which libtool)) == "/usr/bin/libtool" ]]; then
> + ltconfig='/usr/share/libtool/config'
> else
> echo "Autoconf helper path not found $ltconfig_error"
> echo " expected at: '$ltpath/../share/libtool/config'"
> ]]]
>
> (Beware Bash-isms.)
>
> It looks to me like this could/should be more general. Anybody care to
> suggest how?
- Julian
Re: APR's check for installed libtool is inconsistent
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote (to dev@subversion.a.o):
> On 26.02.2018 18:39, Julian Foad wrote:
>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>> duplicates this.)
>>
>> APR's 'build/buildcheck.sh' says:
>> [[[
>> # Require libtool 1.4 or newer
>> libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
>> ...
>> ]]]
>>
>> and fails if it doesn't find a 'libtool' binary at version >= 1.4;
>>
>> but 'buildconf' says:
>> [[[
>> build/buildcheck.sh $verbose || exit 1
>>
>> libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
>> libtoolize14 libtoolize`
>> ]]]
>>
>> Different tool name, different order of checking for versions of it.
>>
>> This difference caused a problem on my Ubuntu 16.04 system, where only
>> the main 'libtool' package was installed which provides only a
>> 'libtoolize' binary, and the optional 'libtool-bin' package which adds
>> a 'libtool' binary was not installed. I was able to install the latter
>> to work around this issue.
>
> FWIW, Subversion's autogen.sh and build/buildcheck.sh only look for
> 'libtoolize' in one of its aliased names, it doesn't look for 'libtool'
> at all, since about 3 years ago.
>
>> Looks like it should be changed to be consistent. What do you think?
>
> +1 to duplicating Subversion's logic for finding libtoolize in APR.
Subversion's 'autogen.sh' says:
[[[
# Much like APR except we do not prefer libtool 1 over libtool 2.
libtoolize="`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`"
]]]
Subversion's 'build/buildcheck.sh' says:
[[[
# Much like APR except we do not prefer libtool 1 over libtool 2.
libtoolize=${LIBTOOLIZE:-`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`}
]]]
In addition, my colleague Michael reports Subversion's 'autogen.sh'
does not find the 'aclocal' and 'libtool' directories on CentOS 7.
A patch equivalent to this one works:
[[[
Index: autogen.sh
===================================================================
--- autogen.sh (revision 1825663)
+++ autogen.sh (working copy)
@@ -81,6 +81,8 @@ if [ "x$LIBTOOL_M4" = "x" ]; then
ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
if [ -d "$ltpath/../share/aclocal/." ]; then
ltm4=`cd "$ltpath/../share/aclocal" && pwd`
+ elif [[ $(readlink -f $(which aclocal)) == "/usr/bin/aclocal" ]]; then
+ ltm4='/usr/share/aclocal'
else
echo "Libtool helper path not found $ltm4_error"
echo " expected at: '$ltpath/../share/aclocal'"
@@ -129,6 +131,8 @@ if [ $lt_major_version -ge 2 ]; then
ltconfig=`cd "$ltpath/../share/libtool/config" && pwd`
elif [ -d "$ltpath/../share/libtool/build-aux/." ]; then
ltconfig=`cd "$ltpath/../share/libtool/build-aux" && pwd`
+ elif [[ $(readlink -f $(which libtool)) == "/usr/bin/libtool" ]]; then
+ ltconfig='/usr/share/libtool/config'
else
echo "Autoconf helper path not found $ltconfig_error"
echo " expected at: '$ltpath/../share/libtool/config'"
]]]
(Beware Bash-isms.)
It looks to me like this could/should be more general. Anybody care to
suggest how?
- Julian
Re: APR's check for installed libtool is inconsistent
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote (to dev@subversion.a.o):
> On 26.02.2018 18:39, Julian Foad wrote:
>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>> duplicates this.)
>>
>> APR's 'build/buildcheck.sh' says:
>> [[[
>> # Require libtool 1.4 or newer
>> libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
>> ...
>> ]]]
>>
>> and fails if it doesn't find a 'libtool' binary at version >= 1.4;
>>
>> but 'buildconf' says:
>> [[[
>> build/buildcheck.sh $verbose || exit 1
>>
>> libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
>> libtoolize14 libtoolize`
>> ]]]
>>
>> Different tool name, different order of checking for versions of it.
>>
>> This difference caused a problem on my Ubuntu 16.04 system, where only
>> the main 'libtool' package was installed which provides only a
>> 'libtoolize' binary, and the optional 'libtool-bin' package which adds
>> a 'libtool' binary was not installed. I was able to install the latter
>> to work around this issue.
>
> FWIW, Subversion's autogen.sh and build/buildcheck.sh only look for
> 'libtoolize' in one of its aliased names, it doesn't look for 'libtool'
> at all, since about 3 years ago.
>
>> Looks like it should be changed to be consistent. What do you think?
>
> +1 to duplicating Subversion's logic for finding libtoolize in APR.
Subversion's 'autogen.sh' says:
[[[
# Much like APR except we do not prefer libtool 1 over libtool 2.
libtoolize="`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`"
]]]
Subversion's 'build/buildcheck.sh' says:
[[[
# Much like APR except we do not prefer libtool 1 over libtool 2.
libtoolize=${LIBTOOLIZE:-`./build/PrintPath glibtoolize libtoolize glibtoolize1 libtoolize15 libtoolize14`}
]]]
In addition, my colleague Michael reports Subversion's 'autogen.sh'
does not find the 'aclocal' and 'libtool' directories on CentOS 7.
A patch equivalent to this one works:
[[[
Index: autogen.sh
===================================================================
--- autogen.sh (revision 1825663)
+++ autogen.sh (working copy)
@@ -81,6 +81,8 @@ if [ "x$LIBTOOL_M4" = "x" ]; then
ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
if [ -d "$ltpath/../share/aclocal/." ]; then
ltm4=`cd "$ltpath/../share/aclocal" && pwd`
+ elif [[ $(readlink -f $(which aclocal)) == "/usr/bin/aclocal" ]]; then
+ ltm4='/usr/share/aclocal'
else
echo "Libtool helper path not found $ltm4_error"
echo " expected at: '$ltpath/../share/aclocal'"
@@ -129,6 +131,8 @@ if [ $lt_major_version -ge 2 ]; then
ltconfig=`cd "$ltpath/../share/libtool/config" && pwd`
elif [ -d "$ltpath/../share/libtool/build-aux/." ]; then
ltconfig=`cd "$ltpath/../share/libtool/build-aux" && pwd`
+ elif [[ $(readlink -f $(which libtool)) == "/usr/bin/libtool" ]]; then
+ ltconfig='/usr/share/libtool/config'
else
echo "Autoconf helper path not found $ltconfig_error"
echo " expected at: '$ltpath/../share/libtool/config'"
]]]
(Beware Bash-isms.)
It looks to me like this could/should be more general. Anybody care to
suggest how?
- Julian
Re: APR's check for installed libtool is inconsistent
Posted by Branko Čibej <br...@apache.org>.
On 26.02.2018 18:39, Julian Foad wrote:
> (CC'ing Subversion as Subversion's build system both uses and kind-of
> duplicates this.)
>
> APR's 'build/buildcheck.sh' says:
> [[[
> # Require libtool 1.4 or newer
> libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
> ...
> ]]]
>
> and fails if it doesn't find a 'libtool' binary at version >= 1.4;
>
> but 'buildconf' says:
> [[[
> build/buildcheck.sh $verbose || exit 1
>
> libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15
> libtoolize14 libtoolize`
> ]]]
>
> Different tool name, different order of checking for versions of it.
>
> This difference caused a problem on my Ubuntu 16.04 system, where only
> the main 'libtool' package was installed which provides only a
> 'libtoolize' binary, and the optional 'libtool-bin' package which adds
> a 'libtool' binary was not installed. I was able to install the latter
> to work around this issue.
FWIW, Subversion's autogen.sh and build/buildcheck.sh only look for
'libtoolize' in one of its aliased names, it doesn't look for 'libtool'
at all, since about 3 years ago.
> Looks like it should be changed to be consistent. What do you think?
+1 to duplicating Subversion's logic for finding libtoolize in APR.
-- Brane