[Apologies for sending this follow-up a month after most of the other
messages -- I've been a bit busy. I hope that I haven't missed any
messages or repeated anything obvious.]
On Sun, 2 Mar 2003, Matthew Wilcox wrote:
> Subject: gnat-3.2 transition plan
>
> First, what packages are affected? On my i386-unstable box, only the
> following packages depend on either gnat or libgnat-3.14p-1
> [...]
> (why don't libadaodbc1 or libadasockets0 show up on this?
I don't think libadasockets0 needs to depend on gnat -- it is, I
think, `just' a shared object library. However, there is clearly an
expectation that the program linking with it is compiled with gnat so
that the Ada-related symbols are all resolved. Perhaps it should
recommend gnat or libgnat.
On Sun, 2 Mar 2003, Florian Weimer wrote:
> Subject: Re: GNAT 3.15p transition plan
> > Florian, I don't agree. I understand your arguments but honestly,
> > there is no more than one ACT release per year. So people don't
> > have to often rebuilt their programs and libraries.
> I've looked at a few packages which would need DSOs and I came to the
> conclusion that I simply do not have the time to take care of them
> properly.
>
> If someone else stepped in and helped with the various library
> packages, I wouldn't object, of course.
I've just adopted adasockets (well, I had an ITA open on it for long
enough), and hope to do the same for libgtkada (If someone else
with more time wishes to adopt it instead of me, feel free. Just let
me know.)
Personally, I would like to keep shared library support for gnat, for
reasons already explained in other replies. However, to do that, we
do need to sort out the ABI and related version problems:
We already have an ABI-like issue whereby .ali files are tied to the
gnat version (i.e., 3.14 or 3.15) (see the open bugs in adacgi). I
wonder how that will relate to the library packaging guidelines if we
have gnat-3.2 co-existing with gnat? I.e., whereas gnat_3.15 will
replace gnat_3.14, what happens if gnat_3.15 and gnat-3.2 want to use
the same library? Do we then have a version of each library (i.e.,
.o, .ali, and .so files) for gnat and another for gnat-3.2?
The simple alternative is to not package any .ali, .o, .so files, and
have the Ada library packages provide only source code. Of course,
until gnat-3.2 is viable, is it worth worrying about this? (This
solution would mean effectively dropping shared libraries.)
Ignoring gnat-3.2 for a moment: As noted in other messages, there
doesn't seem to be a huge amount of work to convert packages from gnat
3.14 to 3.15 (just change the Depends/Build-Depends). If I understand
correctly, the testing scripts will stop gnat 3.15 going from unstable
to testing until the packages that have dependencies on gnat 3.14 have
been changed to 3.15. So it should be clear what work needs doing
when the gnat version changes.
My last point in this (increasingly incoherent) email: I don't yet
know if the actual .so files still work with a later version of gnat.
I.e., given the scenerio:
- Build library package libfoo with gnat 3.14, so the .ali files are
associated with gnat 3.14.
- Build application bar, which links to libfoo.so. As part of the
build of bar, we have to use the libfoo .ali files, so we use gnat
3.14.
- We upgrade to gnat 3.15.
Will bar still work with libfoo.so if foo.so hasn't been rebuilt?
(Yes, I say.)
Will bar still work with libfoo.so when libfoo has been rebuilt with
gnat 3.15 and bar has not been recompiled? (Or are some of the
symbols in libfoo.so linked to something unique to gnat 3.14?)
(I don't know about this one)
Hope all the makes sense!
Cheers,
Phil.
