On Jul 12, 2010, at 11:06 AM, Alan W. Irwin wrote: > On 2010-07-12 10:56-0600 Orion Poplawski wrote: > >> On 07/08/2010 06:43 PM, Jerry wrote: >>> >>> On Jul 8, 2010, at 9:37 AM, Orion Poplawski wrote: >>> >>>> gcc 4.5 just landed in Fedora rawhide. Now getting the following >>>> error >>>> building Ada examples. Looks like we may need to add -llapack to >>>> the link, >>>> but not sure where this should be done. >>> >>> GNAT (GNU Ada Translator) 2005 and 2012 require LAPACK and BLAS >>> libraries to implement certain numeric functionality. I'm not sure >>> where in the gcc series this entered but I think it was 4.3. In the >>> Ada Reference Manual this functionality is described in Annex G.3. >>> >>> You might have both C and Fortran versions of these libraries--OS X >>> does. Ada can handle either (in principle) and I don't think it >>> matters which one is used. I don't know which is currently being >>> linked on OS X without looking into it. (Actually, I think OS X puts >>> them both into the same framework which could mean in the same >>> library.) >>> >>> There is a build flag in PLplot to indicate the presence or >>> absence of >>> Ada 2005 (versus Ada 95) but we should probably move towards using >>> it >>> when possible as this compiler becomes more widespread. >>> >>> In PLplot, there is minimal usage of this functionality--only some >>> type declarations for arrays of floating point numbers. If the flag >>> for Ada 2005 is not set, cmake causes these declarations to be >>> made in >>> the bindings themselves. So if you don't want to link the libraries, >>> you should be able to proceed with PLplot by adjusting the flag. >> >> It seems to me then that if I specify Ada 2005(7), the plplot build >> system >> should add lapack and blas to the appropriate link command. > > The current situation is more primitive than that (see ada.cmake). If > you specify HAVE_ADA_2007, then our Ada interface takes advantage of > certain limited Ada 2005 capabilities, but there is no check that the > Ada compiler has such capabilities, and that option certainly has > nothing directly to do with whether the Ada compiler requires > lapack/blas or not. > > Ideally, what we would like to do is an Ada version check to see > whether > the current version is greater than or equal to the first version > (4.5?) where lapack/blas need to be linked in and the first > version (4.0?) which has the limited Ada 2005 capabilities required > by HAVE_ADA_2007. Once we have those version checks implemented, no > intervention by the user will be required, and we can simply do the > right thing (link in lapack/blas when needed, and set > HAVE_ADA_2007 when possible). > > I am willing to add those version checks with 4.5 and 4.0 tentatively > used for the two separate version limits, but, Jerry, can you get me > more refined numbers for those limits (especially the last one which > is > just a crude guess on my part at this time)?
I've put this to the gurus at comp.lang.ada. I'm beginning to have second thoughts about whether this HAVE_ADA_2007 business is worth the trouble. If the flag is not set, the Ada bindings still work fine if the compiler is Ada 95 or Ada 2005. None of the lapack and blas stuff is actually used--only two lines of declarations are used from the Ada modules and these are already inserted into the bindings if the flag is not set. I think maybe requiring the linking of these large libraries is a bad idea and that I over-engineered the bindings just to get the two declarations in the case of 2005. How much work would it be to just remove this flag? I can fix the binding files (which currently end in .cmake because they are not actually legal Ada files with the @stuff@ in them) which would make people browsing the source code before building it less confused. Jerry > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
