Bugzilla Bug 151343

At the irc discussion with dcoutts today the issue has come up that we put
aside for Ada, but that seems more severe in Haskell case. That is if you have
one lib depend on another, when you install compilers you may get emerges of
the libs fail, when eclass attempts to emerge the lib that depends on another
that was not built for the now-present compiler. In our case, having may be the
whole one incidence of such dependency (gtkada on xmlada IIRC) it was not
really an issue at this stage yet. But if we keep adding more stuff to the tree
we may facethis problem as well (for example GPS is not transitioned to new
system yet. When it is, we may start facing this problem for real).

The fully flexible resolution will likely require support from portage, which
is unrealistic to expect to happen in foreseeable future. Here I will describe
the simplified alternative, which I think should work and be easy to implement.

Basically we will require the user to pick his collection of "primary"
compilers and list them in some file. Something like gnat-gpl-3.4,
gnat-gcc-4.1. I think about requiring both name and a SLOT info in that list -
otherwise stuff will break when new slot of some compiler comes alive. Then the
eclass gets modified to

1. Enforce that some version of selected compiler-SLOT combination is already
emerged - for every such entry on the list

2. Emerges the selected package for all the compilers on the list.

Originally I had "and only for the ones on the list" there, but now I think we
may have some option selecting whether to restrict libs to be built only for
the "primary" compilers or allow them to be built for all installed..

Another note: this really only concerns the libs, as final executables that do
not really care with what lib they were built, as long as it is available, do
not need to use gnat.eclass.

George

On more remark.

There is a straightforward way of dealing with this situation of multiple
compilers. That is to split lib packages. But this quickly becomes a mess with
lots of duplicated code, as one has more and more compilers. One way to avoid
code duplication would be to introduce eclasses, but that would pretty much
mean one eclass per (original, nonsplit) package, which is only sensible if we
had per-category eclasses or something like that :).

George

Sounds like this issue is related to issues on multilib systems (where
libraries are compiled for different ABIs on the same system).  There are
various approaches for this in toolchain; one is to build for all ABIs (which
means the existing atoms/dependencies don't change; changes to portage are
relatively simple), another is to add ABI information to the dependencies
(which obviously requires a change to the portage EABI).  One special case is
sys-libs/glibc which does some trickery in its ebuild to get the library built
for all ABIs.

Note also that in the main toolchain, switching ABIs is a matter of supplying
the right switches to the compiler.  I don't suppose gnat-4.x can be told to
generate for the gnat-3.x ABI?

Is that what this issue is?  I.e. has the ABI changed between versions of the
compiler such that libraries built with different versions of the compiler are
incompatible?

If so, perhaps it would be a good idea to bring in people working on multiple
ABI systems from toolchain.  It would be sensible to try to have a similar
approach for both.

Yes, the issue is indeed the incompatible ABIs, with the difference being, as
you outlined, that we cannot simply set some flags, but rather need to run
eselect gnat set to switch compilers..

I agree that it makes sense to bring in the people from toolchain. I added
toolchain@g.o to CC, is anything else necessary?

toolchain people: Please take a look. It looks like we are facing a common
problem here, so we may as well produce a common solution :).
You can look at #111340 for more details on Ada particulars if you wish, just
beware, it is long. It even may be more sensible to read it somewhat
backwards..

George

(In reply to comment #2)

> Is that what this issue is?  I.e. has the ABI changed between versions of the
> compiler such that libraries built with different versions of the compiler are
> incompatible?

I can't speak for ADA folk, but it's exactly the issue that other languages
face, eg Python and GHC are not ABI compatible between different major
versions.
That is the libs are not compatible (though upstream have considered this issue
so they are parallel installable for different compiler versions).

> If so, perhaps it would be a good idea to bring in people working on multiple
> ABI systems from toolchain.  It would be sensible to try to have a similar
> approach for both.

That'd be great.

Unlike arch ABIs, we're using different compiler versions so we can't always
guarantee that each package will build for every installed version of the
compiler. So I think we have to deal with actually keeping track of which
compiler versions a lib is slotted on. Fortunately portage now has slot deps
which I expect will be part of the solution.

SLOT="${PV}-${ABI}"
DEPEND="dev-thing/foo-1.0 : ${ABI}"

the problem here of course is that ABI can't be a normal var since it's not a
constant a cache generation time. But you get the idea, this is the sort of
thing I've been imagining.

So, this is not such a hot topic after all?
Upon updating some libs I realized we have more than singular cross-dependency.
As it stands now:
adadoc -> xmlada
gps -> gtkada
adaopengl -> adabindx

Still not that many, but nonetheless this makes me think about actually adding
the guarding mechanism that I described in the opening comment. One more detail
- I though about list (of "primary" compiler) location. I think it makes sence
to track it unde /etc, something like /etc/ada/primary-compilers.

George

For the lack of other proposals I will go ahead with what I described in the
opening comment. However the solution will have to be enhanced, since now we
are starting to see Ada-2005 compilers coming out and some libs start to
require that version and, correspondingly, will have to be built for a subset
of primary compilers. Here is how it stands as of now:

1. Some compilers are designated as primary. All the libs using gant.eclass are
built for these compilers only. Other compilers that are installed but are not
on the list are considered "trial" and are not used to build the libs.

2. The "list" actually consists of multiple files, - one for each version of
Ada standard that for which we have compilers. Right now that would be two:
ada-1995 and ada-2005. Good location to keep these files seems to be a
directory (instead of a single file, as was proposed before)
/etc/ada/primary-compilers/. This is selected to be under /etc since this is
supposed to be user-configurable.

3. Final touch, to make dependencies consistent and pull in the right compiler
if user decides to emerge, say, qtada directly. A new virtual: virtual/ada will
be introduced. virtual/gnat is used right now to track compiler backends and
this one will be used to track standard versions.

Comments, problems? I'll try to get around to actually implementing this some
time soon I hope :).

George

So, I finally implemented this enhancement. It actually went better than I
expected.

Final setup, as it got implemented:
1. Primary compilers
1.1 There is only one list for users to edit - /etc/ada/primary_compilers,
which simply contains gnat profiles that user want to regularly use listed one
per line. For example mine at the moment contains:
$ cat /etc/ada/primary_compilers
x86_64-pc-linux-gnu-gnat-gcc-4.2
x86_64-pc-linux-gnu-gnat-gpl-4.1

1.2. The lib_compile and lib_install functions are now looped only over the
installed compilers on that list, not all as before. Nice prat is that this did
not require much code changes, in fact very minor - replacing one function call
(find_compilers with find_primary_compilers) and, naturally, implementing that
function (an ~ 3-liner).

1.3. Added a check to gnat_pkg_setup to verify that all requested primary
compilers are in fact installed (to avoid problems with dependencies, as
discussed in the opening of the bug) - this was one of the principal driving
forces behind doing this whole thing after all..

2. Depending on a particular Ada standard
2.1 virtual/ada has been added to track Ada standard variants. Right now it
contains ada-1995 and ada-2005. Last one only has ...-gnat-gpl-4.1, however
gnat-gcc-4.3 may be added soon, depending on whether qtada will build with it
when it gets released (this is the most Ada-2005 demanding package atm)

2.2 ebuilds simply specify the required dependency on virtual/ada or
virtual/ada-2005, etc. as usual and gnat.eclass takes care of the rest (that is
further reducing the list of considered compilers with which the lib gets
built)

Everything seems to work fine so far. However users need to be notified of the
following change:
Now it is necessary to modify the /etc/ada/primary_compilers file and list
there all but only those gnat compilers that are intended for regular use.
Compilers not listed in that file will not be used for building libs, however
may be activated and used transiently as usual. To provide some basic
"protection" the first gnat installation populates the file with its own
profile, to make sure users have something in there and lib emerges do not just
fail. Hand-editing is nonetheless necessary "for best results".

As far as I am concerned all the issues raised in this bug have been resolved
as of now, so, considering that there was not much activity otherwise, I am
going to close it.

George