[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNAT 3.15p



Florian Weimer <fw@deneb.enyo.de> writes:

> Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> 
> >> The users will receive annoying warnings from ldconfig, so this is not
> >> an option.
> >
> > I tried it on the binary distribution of GNAT 3.15p.  I did not get
> > any warnings:
> 
> Hmm, I can't reproduce it right now.  But it looks to me like a policy
> violation.

FWIW, I've done some extensive research on several GNU/Linux
distributions, and even FreeBSD, to see how they handled this soname
issue.  You'll notice that most distros never included the ACT public
version of GNAT, and started shipping Ada only after GCC 3.2 went out.

(sorry for the long lines)

Variant Version Distribution  Shared libraries                          soname
-------------------------------------------------------------------------------------------
ACT     3.07    binary tgz    /usr/lib/libgnat.so.3.07                  libgnat.so
ACT     3.09    binary tgz    /usr/lib/libgnat.so.3.09                  libgnat.so
ACT     3.12p   Red Hat 7.0   /usr/lib/libgnat-3.12p.so.1.12            libgnat-3.12p.so.1
ACT     3.13p   Ada for Linux /usr/lib/libgnat-3.13p.so.1.8             libgnat-3.13p.so.1
ACT     3.13p   Red Hat 7.1   /usr/lib/libgnat-3.13p.so.1.13            libgnat-3.13p.so.1
ACT     3.13p   SuSE 8.0      /usr/lib/libgnat-3.13p.so.1.7             libgnat-3.13p.so.1
ACT     3.14p   Debian woody  /usr/lib/libgnat-3.14p.so.1.1             libgnat-3.14p.so.1
ACT     3.14p   FreeBSD 4.7   /usr/local/lib/libgnat-3.14.so.1          libgnat-3.14.so.1
ACT     3.15p   FreeBSD 4.8   /usr/local/lib/libgnat-3.15.so.1          libgnat-3.15.so.1
ACT     3.15p   binary tgz    <prefix>/lib/gcc-lib/.../libgnat-3.15.so  libgnat-3.15.so
ACT     3.15p   from source   <prefix>/lib/gcc-lib/.../libgnat-3.15.so  libgnat-3.15.so
FSF     3.2     Mandrake 9.0  /usr/lib/libgnat-3.15a.so.1               libgnat-3.15a.so.1
FSF     3.2     Red Hat 8     /usr/lib/libgnat-3.15a.so.1               libgnat-3.15a.so.1
FSF     3.2     SuSE 8.1      /usr/lib/libgnat-3.15a.so                 libgnat-3.15a.so
FSF     3.2.2   ASPLinux      /usr/lib/libgnat-3.15a.so.1               libgnat-3.15a.so.1
FSF     3.2.2   Mandrake 9.1  /usr/lib/libgnat-3.15a.so.1               libgnat-3.15a.so.1
FSF     3.2.2   Red Hat 9     /usr/lib/libgnat-3.15a.so.1               libgnat-3.15a.so.1
FSF     3.2.2   Yellow Dog    /usr/lib/libgnat-.so.1                    libgnat-.so.1
FSF     3.2.3   Debian sarge  none                                      none
FSF     3.3     Polish Linux  /usr/lib/libgnat-3.15.so.1                libgnat-3.15.so.1
FSF     3.3     SuSE 8.2      /usr/lib/libgnat-3.15.so                  libgnat-3.15.so
FSF     3.3     from source   <prefix>/lib/gcc-lib/.../libgnat-3.15.so  libgnat-3.15.so
FSF     3.3.1   Debian sarge  none                                      none

First, please note that Debian is the only distro that does not ship
shared libraries with the FSF variant of GNAT; all other distros agree
that shared libraries are a good thing.

All distributions of the ACT releases have historically ignored the
ACT default soname and used the same pattern, libgnat-x.xxp.so.1.
This includes Debian woody.

Most of the recent distributions seem to have dropped ACT releases
altogether, in favour of FSF ones.  This is unfortunate, because the
ACT releases are more mature and stable.  I would like Debian to
include GNAT 3.15p.

The soname for FSF versions is also ill-chosen, and is very likely to
change when ACT finally declares the integration between the Ada
front-end and the GCC 3.x back-end to be complete.  GCC 3.2 does not
have a problem, but GCC 3.3 uses the same soname as ACT's binary
distribution.  This is bad, given the ABI incompatibility.

In order to ensure that the soname used by ACT and FSF variants remain
different, I think the best is to keep the current scheme for the
soname (libgnat-3.15p.so.1), and to add a prominent warning to this
effect in the description of the package.  This has the additional
advantage of sticking to the Debian policy.

-- 
Ludovic Brenta.




Reply to: