Julian Foad wrote:
> Branko Čibej wrote (to dev_at_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
Received on 2018-03-02 13:34:28 CET