You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2015/07/12 07:24:56 UTC
subversion-1.9.0-rc2 autogen.sh script breaks "/usr/share/aclocal"
discovery on Fedora 21 and otherws
Building subversion-1.9.0-rc2 with 'autogen.sh' encounters some issues
with recent versions of Fedora.
1) Fedora decided to discard "/bin", and make it a symlink to
"/usr/bin", in what I consider an ill-advised discarding of the File
System Hierarchy.
2) Fedora elected to keep "/bin" in front of "/usr/bin" in PATH,
despite the fact that *everything* from /usr/bin is now in /bin, and
vice versa. This has changed the default path discoverd for
*everything* in /usr/bin.
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
if [ "x$LIBTOOL_M4" = "x" ]; then
ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
if [ -d "$ltpath/../share/aclocal/." ]; then
Re: subversion-1.9.0-rc2 autogen.sh script breaks
"/usr/share/aclocal" discovery on Fedora 21 and otherws
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Mon, Jul 13, 2015 at 23:12:16 +0000:
> Nico Kadel-Garcia wrote on Sun, Jul 12, 2015 at 14:08:25 -0400:
> > 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:
> > >> +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,
> >
>
> Actually I can, but that's besides the point. We need autogen.sh to
> work no matter what the /bin symlink points to.
In more words: it's entirely possible that there is a system where /bin
is a symlink that points to some location other than /usr/bin, and we
need to work on that system too — even if we don't know about it.
(Of course this whole sub-discussion becomes moot if we use
--print-ac-dir, as discussed elsethread.)
Cheers,
Daniel
Re: subversion-1.9.0-rc2 autogen.sh script breaks
"/usr/share/aclocal" discovery on Fedora 21 and otherws
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Sun, Jul 12, 2015 at 14:08:25 -0400:
> 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:
> >> +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,
>
Actually I can, but that's besides the point. We need autogen.sh to
work no matter what the /bin symlink points to.
> > 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.
Okay.
By the way, this thread should move to the dev@ list; feel free to
restart/summarize the discussion there.
Cheers,
Daniel
Re: subversion-1.9.0-rc2 autogen.sh script breaks "/usr/share/aclocal"
discovery on Fedora 21 and otherws
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
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
Re: subversion-1.9.0-rc2 autogen.sh script breaks
"/usr/share/aclocal" discovery on Fedora 21 and otherws
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.
> 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.
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?
Daniel
> if [ "x$LIBTOOL_M4" = "x" ]; then
> ltm4_error='(try setting the LIBTOOL_M4 environment variable)'
> if [ -d "$ltpath/../share/aclocal/." ]; then