On Sun, Jul 12, 2015 at 3:09 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Nico Kadel-Garcia wrote on Sun, Jul 12, 2015 at 01:24:56 -0400:
>> Building subversion-1.9.0-rc2 with 'autogen.sh' encounters some issues
>> with recent versions of Fedora.
>
> Why are you running autogen.sh? It's required when building from
> a checkout, it's not required when building from a tarball.
Except when it is required, because of autoconf and aclocal version
incompatiblites. So it's a very common upstream Fedora/RHEL RPM
building standard.
>> 3) Subversion 1.9's autogen.sh tries to determine the location of
>> /usr/share/local by finding the "aclocal" binary, which now is found
>> in "/bin/aclocal" instead of "/usr/bin/aclocal". It then looks in
>> "/bin/../share/aclocal" for the libtool.m4., Hilarity ensues.
>>
>> It's not a hard patch, and I've included it below.
>>
>> --- subversion-1.9.0-rc2/autogen.sh.libtool 2015-02-13
>> 15:36:06.000000000 -0500
>> +++ subversion-1.9.0-rc2/autogen.sh 2015-07-04 01:35:24.683176737 -0400
>> @@ -76,7 +76,10 @@
>> $libtoolize --copy --automake --force
>>
>> ltpath="`dirname $libtoolize`"
>> -
>> +if [ -L "$ltpath" -a "$ltpath" = "/bin" ]; then
>> + # Avoid "/bin" symlink to "/usr/bin" confusion
>> + ltpath=/usr/bin
>> +fi
>
> We can't presume that /usr/bin is the target of /bin when the latter is
> a symlink. That's not necessarily true everywhere.
Can you think of a specific instance where "libtool" is in
"/bin/libtool" where this would not apply? In all circumstance I know
of where "/bin" is a symlink with "libtoolize" in it, it's the case,
especially in the new "let's throw out the File System Hierarchy and
let's play 'I'm smarter than you, neener neener neener'" with PATH
and symlinks
In case it's not clear, I'm a bit cross with Fedora's decision to do
this. The reason to keep "/bin" with small, static binaries or
libraries only in "/lib" or "/lib64" was because in yesteryear, "/usr"
was often on a separate disk. much larger disk than "/", and this
protected small recovery and bootstrapping tools on "/". It also kept
critical recovery binaries and libraries out of the more dynamically
modified "/usr" components..
> I see there's a "aclocal --print-ac-dir" flag which seems to just print
> the path we need. Does that help? Can we eg first look for aclocal in
> PATH and then run that command to find the share/aclocal dir?
This would make sense if the tool was written to look for "aclocal".
It's not, it's set to look for "libtoolize", for reasons I'm uncertain
of. That actually makes more sense. Let me think about that.
> Daniel
>
>> if [ "x$LIBTOOL_M4" = "x" ]; then
>> ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
>> if [ -d "$ltpath/../share/aclocal/." ]; then
Received on 2015-07-12 20:08:39 CEST