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!news4.google.com!proxad.net!feeder1-2.proxad.net!news.wiretrip.org!feeder1.cambrium.nl!feeder3.cambrium.nl!feed.tweaknews.nl!not-for-mail From: Ludovic Brenta 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> <873apf6j4v.fsf@willow.rfc1149.net> Date: Mon, 21 Apr 2008 23:05:33 +0200 Message-ID: <87od82c40y.fsf@ludovic-brenta.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:9MAmSt1KXWtloMM6455NTlyRPt0= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Tele2 X-Trace: DXC=YUA^?OBTA`BOFamGDgl`YA6`Y6aWje^YJXfgM_lcIGoF Samuel Tardieu writes: >>>>>> "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. That's a thought. In that case, it would be nice to investigate how easy it is for the programmer to link with libgnala.a and lapack. For example, libgnala.a is currently installed in /usr/lib/gcc/x86_64-linux-gnu/4.3/rts-native/adalib/ without any symlink to it from /usr/lib, and so linking with it may require ugly linker options (ugly because they depend on the OS and version of GCC). >>> 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. Yes indeed. > 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 :) Now I see what you mean, i.e. the lapack shared library will cause the new package to depend on the lapack package. I agree that it doesn't make much of a difference in the end. However, it is still necessary that whatever package contains a (now hypothetical) libgnala.so depend on lapack. Good taste, as you put it, requires that shared library dependencies be captured in the package system. > 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. Cool! -- Ludovic Brenta.