From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,235659b21b3d24ab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-29 13:16:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!151.189.0.75!newsfeed.germany.net!newsfeed2.easynews.net!easynews.net!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Will there be a 3.14p version of GNAT? Date: Sat, 29 Sep 2001 22:38:01 +0200 Organization: Enyo's not your organization Message-ID: <87u1xlpwba.fsf@deneb.enyo.de> References: <2t2r7.26711$QK.21818615@news1.sttln1.wa.home.com> <8766aajjvh.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: archiver1.google.com comp.lang.ada:13521 Date: 2001-09-29T22:38:01+02:00 List-Id: Ted Dennison 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.