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

Reply via email to