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-Thread: 103376,73a6dbe06e1250ce X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!news.glorb.com!club-internet.fr!feedme-small.clubint.net!proxad.net!feeder1-1.proxad.net!cleanfeed3-b.proxad.net!nnrp20-2.free.fr!not-for-mail From: Samuel Tardieu Newsgroups: comp.lang.ada Subject: Re: gnatmake: "ada.numerics.real_arrays" is not a predefined library unit References: <480c8879$0$4768$9b4e6d93@newsspool3.arcor-online.net> <2c24b560-608c-4a10-a64c-7dff14b19e21@u12g2000prd.googlegroups.com> <87bq436t1l.fsf@willow.rfc1149.net> <87zlrnatmp.fsf@ludovic-brenta.org> Date: Mon, 21 Apr 2008 22:35:44 +0200 Message-ID: <873apf6j4v.fsf@willow.rfc1149.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:A+x7BjIQLnHRDMiXuH+N/uwjUp0= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Leafnode-NNTP-Posting-Host: 2a01:5d8:5138:2f95::3 Organization: Guest of ProXad - France NNTP-Posting-Date: 21 Apr 2008 22:40:01 MEST NNTP-Posting-Host: 88.191.14.223 X-Trace: 1208810401 news-3.free.fr 10698 88.191.14.223:46934 X-Complaints-To: abuse@proxad.net Xref: g2news1.google.com comp.lang.ada:21021 Date: 2008-04-21T22:40:01+02:00 List-Id: >>>>> "Ludovic" == Ludovic Brenta writes: Ludovic> Definitely; this is an area where all distributions would Ludovic> benefit. However, Debian is a bit peculiar since it patches Ludovic> the library building process (in gcc/ada/Makefile.in) heavily Ludovic> so as to build both the zero-cost and setjump/longjump Ludovic> versions of the library. So, if I produce a patch, someone Ludovic> will have to adjust it for upstream GCC. In fact, I've had a look and I'm not sure it is interesting to make a shared version of libgnala at all. It contains mostly generics. >> Concerning the distribution, why separate libgnala.so from libgnat? >> You don't need a dependency on lapack/blas, only a "suggests" or >> "recommends" if people want to build applications requiring annex g >> support. As far as compiled applications are concerned, the >> lapack/blas dependency will be recored as part of a regular Debian >> dependency. Ludovic> "Suggests" or "Recommends" is not good enough because it Ludovic> would foil the automatic dependency management Debian is Ludovic> renowned for. The proper solution is to place libgnala.so in Ludovic> a separate package (suggested or recommended by gnat-4.3) but Ludovic> that Depends on (i.e. requires) lapack to be installed. What is the difference between: - gnat bundles libgnala with gnat, and recommends lapack - gnat recommends libgnala, which depends on lapack (your recommendation) ? In both configurations, someone wanting to use GNAT with Annex G will have to install a package on which GNAT does not depend, be it libgnala or lapack. Ludovic> This way, if someone builds a package where they use Annex G, Ludovic> their package will automatically depend on libgnala.so and, Ludovic> indirectly, on lapack. With your proposal, this would not Ludovic> happen as lapack would be only recommended. With my proposal, someone building a system using Annex G would get a "depends" on lapack through the shared library. With yours, they would get a "depends" on libgnala.so which has in turn a "depends" on lapack. I fail to see the difference, except maybe a matter of taste :) Anyway, I've started investigating the "libgnalasup" issue. This library is referenced by i-forbla.adb, but doesn't seem to be distributed. Replacing it with "liblapack" and "libblas" may be enough. Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/