On Sun, Jul 12, 2015 at 3:09 AM, Daniel Shahaf <d...@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
