Re: Will there be a 3.14p version of GNAT?

[Florian Weimer <fw@deneb.enyo.de>]

Ted Dennison<dennison@telepath.com> writes:

>>> >Are there any ideas how to ensure binary compatibility across GNAT
>>> >builds from different distributors of the same operating system?
>>> 
>>> Pardon me for a naieve question: What exactly, save a source code
>>> modification, would cause such an incompatability?
>>
>>Different sonames for the GNAT run-time library, or a diffent default
>>threading implementation.
>
> I'd say those both qualify as source code modifications.

Hmm, I think this term is misleading.  Certainly these build options
do not require source code modification.

Source code modifications are a different beast.  For example, the
symbolic traceback facility in GNAT 3.13p does not work correctly on
most systems if you have compiled your own version of GNAT from the
sources.  Some GNAT distributors apply code fixes (clearly source code
modifications), which hamper binary compatibility.

> Yeah, the threading bit can be changed by renaming files, or moving
> a link or somesuch. But it is the same issue. If you do any of that,
> you aren't taking the defaults. Everyone who builds as per the
> instructions should get compatable Gnat builds.

Maybe this is true.  However, on a GNU/Linux system, the GNAT 3.13p
binary distribution uses a different default threading library than a
straightforward build from the sources.  (Yes, it's documented.)

> So on to my next naieve question: What exactly is the "nightmare
> scenario" here?

Binaries built by the GNAT toolchain, linked against shared libraries
compiled by GNAT (for example, the run-time library), which work only
on a limited number of systems.

> Say one person has a Linux FSU-threads build, and another has a
> Linux native threads build. What bad things are you worried about
> happening?

The GNU C++ ABI fiasco? ;-)

I think there will be problems sooner or later if you are unable to
exchange dynamically linked executables.  (The Debian Policy has
already been adjusted to reflect the GNAT situation of flakey shared
library support, it is now permitted not to use them.)  

People want shared libraries, and will complain loudly if they can't
run binaries compiled on system A on system B, and blame GNAT (and
Ada) if it doesn't work as they expect.  We don't see such problems
yet because most people interested in Free Software written in Ada
don't rely on distributors to get it, they compile it on their own
(GNAT itself is probably an exception), but if this should ever
change, some mechanisms to ensure binary compatibility should already
be in place.