From: Orion P. <or...@co...> - 2010-07-08 16:38:12
|
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. [ 23%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/bin/gnatgcc -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -c /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada/x01a.adb -o CMakeFiles/x01a.dir/x01a.o Linking Ada executable x01a cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/bin/cmake -E cmake_link_script CMakeFiles/x01a.dir/link.txt --verbose=1 /usr/bin/gnatmake -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aL/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/plplotadad.dir x01a.adb -cargs -largs -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime gcc -c -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada x01a.adb gnatbind -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aO/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/plplotadad.dir -x x01a.ali gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrfXnn': (.text+0x3585): undefined reference to `dgetrf_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getriXnn': (.text+0x35ed): undefined reference to `dgetri_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrsXnn': (.text+0x3751): undefined reference to `dgetrs_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__orgtrXnn': (.text+0x3881): undefined reference to `dorgtr_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__steqrXnn': (.text+0x3923): undefined reference to `dsteqr_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__sterfXnn': (.text+0x3966): undefined reference to `dsterf_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a-nlrear.o): In function `ada__numerics__long_real_arrays__lapack__sytrdXnn': (.text+0x3a0f): undefined reference to `dsytrd_' collect2: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc gnatmake: *** link failed. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Jerry <lan...@qw...> - 2010-07-09 00:44:02
|
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. Note that pretty much everywhere in PLplot including bindings and docs, "Ada 2007" is used instead of "Ada 2005" which is my fault. (The Ada 2005 spec was not finalized until early 2007.) I wonder if a global change is possible without wrecking something. Jerry > > [ 23%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o > cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/ > bin/gnatgcc > -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada > -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -c > /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada/x01a.adb -o > CMakeFiles/x01a.dir/x01a.o > Linking Ada executable x01a > cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/ > bin/cmake -E > cmake_link_script CMakeFiles/x01a.dir/link.txt --verbose=1 > /usr/bin/gnatmake -aI/builddir/build/BUILD/plplot-5.9.6/fedora/ > examples/ada > -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada > -aL/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ > plplotadad.dir > x01a.adb -cargs -largs -rdynamic ../../bindings/ada/ > libplplotadad.so.0.0.0 > ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ > libdl.so > ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 > /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 > /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so > -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ > builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ > plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ > fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime > > gcc -c -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada > -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada x01a.adb > gnatbind -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada > -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada > -aO/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ > plplotadad.dir > -x x01a.ali > gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 > ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ > libdl.so > ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 > /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 > /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so > -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ > builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ > plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ > fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__getrfXnn': > (.text+0x3585): undefined reference to `dgetrf_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__getriXnn': > (.text+0x35ed): undefined reference to `dgetri_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__getrsXnn': > (.text+0x3751): undefined reference to `dgetrs_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__orgtrXnn': > (.text+0x3881): undefined reference to `dorgtr_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__steqrXnn': > (.text+0x3923): undefined reference to `dsteqr_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__sterfXnn': > (.text+0x3966): undefined reference to `dsterf_' > /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- > nlrear.o): In > function `ada__numerics__long_real_arrays__lapack__sytrdXnn': > (.text+0x3a0f): undefined reference to `dsytrd_' > collect2: ld returned 1 exit status > gnatlink: error when calling /usr/bin/gcc > gnatmake: *** link failed. > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane or...@co... > Boulder, CO 80301 http://www.cora.nwra.com > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Jerry <lan...@qw...> - 2010-07-10 00:07:26
|
On Jul 8, 2010, at 5: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. To be more clear, even if you have Ada 2005 (which you do, now), you can tell PLplot that you don't and the build process should still work--it's just cmake making slight tweaks to the Ada bindings to insert the array declarations if you say you don't have Ada 2005. > > Note that pretty much everywhere in PLplot including bindings and > docs, "Ada 2007" is used instead of "Ada 2005" which is my fault. (The > Ada 2005 spec was not finalized until early 2007.) I wonder if a > global change is possible without wrecking something. > > Jerry > >> >> [ 23%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o >> cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/ >> bin/gnatgcc >> -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada >> -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -c >> /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada/x01a.adb -o >> CMakeFiles/x01a.dir/x01a.o >> Linking Ada executable x01a >> cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada && /usr/ >> bin/cmake -E >> cmake_link_script CMakeFiles/x01a.dir/link.txt --verbose=1 >> /usr/bin/gnatmake -aI/builddir/build/BUILD/plplot-5.9.6/fedora/ >> examples/ada >> -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada >> -aL/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ >> plplotadad.dir >> x01a.adb -cargs -largs -rdynamic ../../bindings/ada/ >> libplplotadad.so.0.0.0 >> ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ >> libdl.so >> ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 >> /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 >> /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/ >> libgnat-4.5.so >> -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ >> builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ >> plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ >> fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime >> >> gcc -c -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada >> -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada x01a.adb >> gnatbind -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada >> -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada >> -aO/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ >> plplotadad.dir >> -x x01a.ali >> gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 >> ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ >> libdl.so >> ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 >> /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 >> /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/ >> libgnat-4.5.so >> -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ >> builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ >> plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ >> fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__getrfXnn': >> (.text+0x3585): undefined reference to `dgetrf_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__getriXnn': >> (.text+0x35ed): undefined reference to `dgetri_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__getrsXnn': >> (.text+0x3751): undefined reference to `dgetrs_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__orgtrXnn': >> (.text+0x3881): undefined reference to `dorgtr_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__steqrXnn': >> (.text+0x3923): undefined reference to `dsteqr_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__sterfXnn': >> (.text+0x3966): undefined reference to `dsterf_' >> /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- >> nlrear.o): In >> function `ada__numerics__long_real_arrays__lapack__sytrdXnn': >> (.text+0x3a0f): undefined reference to `dsytrd_' >> collect2: ld returned 1 exit status >> gnatlink: error when calling /usr/bin/gcc >> gnatmake: *** link failed. >> >> -- >> Orion Poplawski >> Technical Manager 303-415-9701 x222 >> NWRA/CoRA Division FAX: 303-415-9702 >> 3380 Mitchell Lane or...@co... >> Boulder, CO 80301 http://www.cora.nwra.com >> >> ------------------------------------------------------------------------------ >> 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 >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Orion P. <or...@co...> - 2010-07-12 16:57:09
|
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. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2010-07-12 18:05:55
|
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)? 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-07-13 02:44:08
|
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 > __________________________ > |
From: Jerry <lan...@qw...> - 2010-07-15 07:52:17
|
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. I guess it's irrelevant now, but for what it's worth, the answers from the oracle are, respectively, 4.3 and 4.2. Jerry > 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)? > > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-07-13 07:20:29
|
On 2010-07-12 19:44-0700 Jerry wrote: > 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 think very little effort would be required to remove HAVE_ADA_2007 from the build system. However, let's wait to do anything about this until we understand the linking issue that Orion reported a lot more. I still think the linking issue may be completely orthogonal to HAVE_ADA_2007. You imply above, that lapack/blas are not used by HAVE_ADA_2007 so it appears to me that Orion's discovery of a lapack/blas linking issue must be completely independent of HAVE_ADA_2007. 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-07-14 09:17:38
|
On Jul 13, 2010, at 12:21 AM, Alan W. Irwin wrote: > On 2010-07-12 19:44-0700 Jerry wrote: > >> 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 think very little effort would be required to remove HAVE_ADA_2007 > from the build system. However, let's wait to do anything about this > until we understand the linking issue that Orion reported a lot more. > I still think the linking issue may be completely orthogonal to > HAVE_ADA_2007. You imply above, that lapack/blas are not used by > HAVE_ADA_2007 so it appears to me that Orion's discovery of a > lapack/blas linking issue must be completely independent of > HAVE_ADA_2007. > > Alan > __________________________ > Alan W. Irwin > No. Orion's result which he reports in the next e-mail is correct and expected. If the HAVE_ADA_2007 flag is set then something in the build process, probably cmake, modifies some Ada files by inserting this declaration: with Ada.Numerics.Long_Real_Arrays; This is somewhat analogous to an include statement in C. Once Ada.Numerics.Long_Real_Arrays is with-ed, the compiler knows that it is supposed to link blas and lapack because a primary function of that package is to provide some quasi-advanced numerics such as finding eigenvectors/eigenvalues and solving Ax=b, etc. (Yes, this is really an official part of Ada now.) PLplot of course needs none of this numeric capability; the only thing that I used from the Ada.Numerics.Long_Real_Arrays package are a couple of convenient (and now standardized) declarations for vectors and matrices which of course are just one- and two-dimensional arrays of double floats of indeterminate sizes. (It occurs to me that this type of discussion might require a knowledge of Ada namespaces which might be different from C namespaces, if C actually has such a concept--that's beyond my C knowledge.) If the flag is not set, then cmake mucks with some of the Ada files to insert equivalent vector and matrix declarations but does not insert the reference to Ada.Numerics.Long_Real_Arrays; thus the compiler has no need to link lapack and blas. Hope that makes sense. Jerry > 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 > __________________________ > |
From: Orion P. <or...@co...> - 2010-07-13 15:47:40
|
On 07/13/2010 01:21 AM, Alan W. Irwin wrote: > > I think very little effort would be required to remove HAVE_ADA_2007 > from the build system. However, let's wait to do anything about this > until we understand the linking issue that Orion reported a lot more. > I still think the linking issue may be completely orthogonal to > HAVE_ADA_2007. You imply above, that lapack/blas are not used by > HAVE_ADA_2007 so it appears to me that Orion's discovery of a > lapack/blas linking issue must be completely independent of > HAVE_ADA_2007. > Nope, if I turn HAVE_ADA_2007 off, it compiles fine. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2010-07-13 17:51:28
|
On 2010-07-13 09:47-0600 Orion Poplawski wrote: > On 07/13/2010 01:21 AM, Alan W. Irwin wrote: >> >> I think very little effort would be required to remove HAVE_ADA_2007 >> from the build system. However, let's wait to do anything about this >> until we understand the linking issue that Orion reported a lot more. >> I still think the linking issue may be completely orthogonal to >> HAVE_ADA_2007. You imply above, that lapack/blas are not used by >> HAVE_ADA_2007 so it appears to me that Orion's discovery of a >> lapack/blas linking issue must be completely independent of >> HAVE_ADA_2007. >> > > Nope, if I turn HAVE_ADA_2007 off, it compiles fine. Thanks, Orion, for that clarification. The rest of this is principally directed to Jerry. Jerry, given that clarification does that firm up your idea of removing HAVE_ADA_2007 because the benefit is rather small for the cost of the the extra lapack/blas dependencies? The rest of this assumes you want to make that change. As far as the build system is concerned, all you have to do to completely disable HAVE_ADA_2007 is to replace option(HAVE_ADA_2007 "Ada 2007?" OFF) with set(HAVE_ADA_2007 OFF CACHE BOOL "Ada 2007?" FORCE) in cmake/modules/ada.cmake. The effect of that last command is to force the OFF value regardless of what the user attempts to set. After that, at your leisure, you can remove any HAVE_ADA_2007 configuration dependencies in the bindings and examples and also in the build system. To help you with that effort, here are the current places where HAVE_ADA_2007 shows up in our source tree. software@raven> find -type f |grep -v .svn| \ grep -v '~$' |xargs grep -l HAVE_ADA_2007 ./doc/docbook/src/ada.xml ./bindings/ada/README.rtf ./bindings/ada/README ./cmake/modules/ada.cmake All of those except ada.cmake are documentation. Looking at that file further, it sets Ada_Is_2007_With_and_Use_Numerics if HAVE_ADA_2007 is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. Those variables show up in the following places in our source tree : software@raven> find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort ./bindings/ada/plplot.adb.cmake ./bindings/ada/plplot.ads.cmake ./bindings/ada/plplot_auxiliary.ads.cmake ./bindings/ada/plplot_thin.ads.cmake ./bindings/ada/plplot_traditional.adb.cmake ./bindings/ada/plplot_traditional.ads.cmake ./cmake/modules/ada.cmake ./examples/ada/x01a.adb.cmake .... ./examples/ada/x31a.adb.cmake ./examples/ada/xthick01a.adb.cmake .... ./examples/ada/xthick31a.adb.cmake software@raven> find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort ./bindings/ada/plplot_auxiliary.ads.cmake ./cmake/modules/ada.cmake I would advise editing all the above *.cmake files to get rid of the references to the variables Ada_Is_2007_With_and_Use_Numerics Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is completed and you have tested it works then you should commit those changes. After that commit I can take over and do the necessary further changes to make those files non-configurable (from the CMake point of view), rename them without the *.cmake index in such a way that we do not lose svn history of those files, and commit all those further changes in such a way that we don't temporarily break PLplot. (That last issue has recently become important since we are using bisect methods to find regressions more and more, and commits that break PLplot interfere with that process unless you laboriously identify all such commits to the svn-bisect software.) 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-07-14 09:18:04
|
On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: > On 2010-07-13 09:47-0600 Orion Poplawski wrote: > >> On 07/13/2010 01:21 AM, Alan W. Irwin wrote: >>> I think very little effort would be required to remove HAVE_ADA_2007 >>> from the build system. However, let's wait to do anything about >>> this >>> until we understand the linking issue that Orion reported a lot >>> more. >>> I still think the linking issue may be completely orthogonal to >>> HAVE_ADA_2007. You imply above, that lapack/blas are not used by >>> HAVE_ADA_2007 so it appears to me that Orion's discovery of a >>> lapack/blas linking issue must be completely independent of >>> HAVE_ADA_2007. >> >> Nope, if I turn HAVE_ADA_2007 off, it compiles fine. > > Thanks, Orion, for that clarification. > > The rest of this is principally directed to Jerry. > > Jerry, given that clarification does that firm up your idea of > removing HAVE_ADA_2007 because the benefit is rather small for the > cost of the the extra lapack/blas dependencies? Yes. > > The rest of this assumes you want to make that change. > As far as the build system is concerned, all you have to > do to completely disable HAVE_ADA_2007 is to replace > > option(HAVE_ADA_2007 "Ada 2007?" OFF) > > with > > set(HAVE_ADA_2007 OFF CACHE BOOL "Ada 2007?" FORCE) > > in cmake/modules/ada.cmake. The effect of that last command is to > force > the OFF value regardless of what the user attempts to set. > After that, at your leisure, you can remove any HAVE_ADA_2007 > configuration dependencies in the bindings and examples and also > in the build system. > > To help you with that effort, here are the current places where > HAVE_ADA_2007 shows up in our source tree. > > software@raven> find -type f |grep -v .svn| \ > grep -v '~$' |xargs grep -l HAVE_ADA_2007 > ./doc/docbook/src/ada.xml > ./bindings/ada/README.rtf > ./bindings/ada/README > ./cmake/modules/ada.cmake > > All of those except ada.cmake are documentation. Looking at that > file further, it sets Ada_Is_2007_With_and_Use_Numerics if > HAVE_ADA_2007 > is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. > > Those variables show up in the following places in our source tree : > > software@raven> find -type f | grep -v .svn | grep -v '~$' | \ > xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort > ./bindings/ada/plplot.adb.cmake > ./bindings/ada/plplot.ads.cmake > ./bindings/ada/plplot_auxiliary.ads.cmake > ./bindings/ada/plplot_thin.ads.cmake > ./bindings/ada/plplot_traditional.adb.cmake > ./bindings/ada/plplot_traditional.ads.cmake > ./cmake/modules/ada.cmake > ./examples/ada/x01a.adb.cmake > .... > ./examples/ada/x31a.adb.cmake > ./examples/ada/xthick01a.adb.cmake > .... > ./examples/ada/xthick31a.adb.cmake > > software@raven> find -type f | grep -v .svn | grep -v '~$' | \ > xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort > ./bindings/ada/plplot_auxiliary.ads.cmake > ./cmake/modules/ada.cmake > > I would advise editing all the above *.cmake files to get rid of the > references to the variables Ada_Is_2007_With_and_Use_Numerics > Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is > completed and you have tested it works then you should commit those > changes. OK. I think I can handle the edit to ada.cmake and to the Ada sources. And it will be nice to have the Ada source in SVN actually be Ada again. Jerry > > After that commit I can take over and do the necessary further changes > to make those files non-configurable (from the CMake point of view), > rename them without the *.cmake index in such a way that we do not > lose svn history of those files, and commit all those further changes > in such a way that we don't temporarily break PLplot. (That last issue > has recently become important since we are using bisect methods to > find regressions more and more, and commits that break PLplot > interfere with that process unless you laboriously identify all such > commits to the svn-bisect software.) > > 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 > __________________________ > |
From: Jerry <lan...@qw...> - 2010-07-22 11:09:58
|
On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: > On 2010-07-13 09:47-0600 Orion Poplawski wrote: > >> On 07/13/2010 01:21 AM, Alan W. Irwin wrote: >>> I think very little effort would be required to remove HAVE_ADA_2007 >>> from the build system. However, let's wait to do anything about >>> this >>> until we understand the linking issue that Orion reported a lot >>> more. >>> I still think the linking issue may be completely orthogonal to >>> HAVE_ADA_2007. You imply above, that lapack/blas are not used by >>> HAVE_ADA_2007 so it appears to me that Orion's discovery of a >>> lapack/blas linking issue must be completely independent of >>> HAVE_ADA_2007. >> >> Nope, if I turn HAVE_ADA_2007 off, it compiles fine. > > Thanks, Orion, for that clarification. > > The rest of this is principally directed to Jerry. > > Jerry, given that clarification does that firm up your idea of > removing HAVE_ADA_2007 because the benefit is rather small for the > cost of the the extra lapack/blas dependencies? > > The rest of this assumes you want to make that change. > As far as the build system is concerned, all you have to > do to completely disable HAVE_ADA_2007 is to replace > > option(HAVE_ADA_2007 "Ada 2007?" OFF) > > with > > set(HAVE_ADA_2007 OFF CACHE BOOL "Ada 2007?" FORCE) > > in cmake/modules/ada.cmake. The effect of that last command is to > force > the OFF value regardless of what the user attempts to set. > After that, at your leisure, you can remove any HAVE_ADA_2007 > configuration dependencies in the bindings and examples and also > in the build system. > > To help you with that effort, here are the current places where > HAVE_ADA_2007 shows up in our source tree. > > software@raven> find -type f |grep -v .svn| \ > grep -v '~$' |xargs grep -l HAVE_ADA_2007 > ./doc/docbook/src/ada.xml > ./bindings/ada/README.rtf > ./bindings/ada/README > ./cmake/modules/ada.cmake > > All of those except ada.cmake are documentation. Looking at that > file further, it sets Ada_Is_2007_With_and_Use_Numerics if > HAVE_ADA_2007 > is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. > > Those variables show up in the following places in our source tree : > > software@raven> find -type f | grep -v .svn | grep -v '~$' | \ > xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort > ./bindings/ada/plplot.adb.cmake > ./bindings/ada/plplot.ads.cmake > ./bindings/ada/plplot_auxiliary.ads.cmake > ./bindings/ada/plplot_thin.ads.cmake > ./bindings/ada/plplot_traditional.adb.cmake > ./bindings/ada/plplot_traditional.ads.cmake > ./cmake/modules/ada.cmake > ./examples/ada/x01a.adb.cmake > .... > ./examples/ada/x31a.adb.cmake > ./examples/ada/xthick01a.adb.cmake > .... > ./examples/ada/xthick31a.adb.cmake > > software@raven> find -type f | grep -v .svn | grep -v '~$' | \ > xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort > ./bindings/ada/plplot_auxiliary.ads.cmake > ./cmake/modules/ada.cmake > > I would advise editing all the above *.cmake files to get rid of the > references to the variables Ada_Is_2007_With_and_Use_Numerics > Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is > completed and you have tested it works then you should commit those > changes. > > After that commit I can take over and do the necessary further changes > to make those files non-configurable (from the CMake point of view), > rename them without the *.cmake index in such a way that we do not > lose svn history of those files, and commit all those further changes > in such a way that we don't temporarily break PLplot. (That last issue > has recently become important since we are using bisect methods to > find regressions more and more, and commits that break PLplot > interfere with that process unless you laboriously identify all such > commits to the svn-bisect software.) > > Alan > __________________________ > Alan W. Irwin > Alan, I have just committed the changes that you describe--all affected Ada files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a (normal) build here but I have succeeded in doing my own private build in my own development system (which bypasses all of the PLplot build stuff) so I know the Ada code is OK. I hope you can make the changes at your end because I suspect that otherwise the build will fail (unless the ada.cmake edit overrides all new evil). Jerry > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-07-22 17:05:55
|
On 2010-07-22 04:09-0700 Jerry wrote: > On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: >> After that commit I can take over and do the necessary further changes >> to make those files non-configurable (from the CMake point of view), >> rename them without the *.cmake index in such a way that we do not >> lose svn history of those files, and commit all those further changes >> in such a way that we don't temporarily break PLplot. (That last issue >> has recently become important since we are using bisect methods to >> find regressions more and more, and commits that break PLplot >> interfere with that process unless you laboriously identify all such >> commits to the svn-bisect software.) > > Alan, > > I have just committed the changes that you describe--all affected Ada > files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a > (normal) build here but I have succeeded in doing my own private build > in my own development system (which bypasses all of the PLplot build > stuff) so I know the Ada code is OK. I hope you can make the changes > at your end because I suspect that otherwise the build will fail > (unless the ada.cmake edit overrides all new evil). Thanks, Jerry. Despite your concern, the build and test continue to work fine after your changes. For example, on Linux "make test_diff_psc" produces this result: ada Missing examples : Differing postscript output : Missing stdout : Differing stdout : adathick Missing examples : Differing postscript output : Missing stdout : Differing stdout : The reason why it works is you have simply removed all configurable @whatever@ strings from the Ada files, but CMake configures those files anyway as a pure copy of the template file. And then the build and test proceeds as normal using those copied files as source. I will now strip out all this configuration machinery so that the template files are treated directly as source files with no need to copy them. A beneficial side benefit of that change is I will be able to rename all of them without the .cmake suffix. This strip out will take some time and care, but I hope to finish it (with similar good test results as above) by late today. 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-07-22 21:29:58
|
On Jul 22, 2010, at 10:07 AM, Alan W. Irwin wrote: > On 2010-07-22 04:09-0700 Jerry wrote: > >> On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: >>> After that commit I can take over and do the necessary further >>> changes >>> to make those files non-configurable (from the CMake point of view), >>> rename them without the *.cmake index in such a way that we do not >>> lose svn history of those files, and commit all those further >>> changes >>> in such a way that we don't temporarily break PLplot. (That last >>> issue >>> has recently become important since we are using bisect methods to >>> find regressions more and more, and commits that break PLplot >>> interfere with that process unless you laboriously identify all such >>> commits to the svn-bisect software.) >> >> Alan, >> >> I have just committed the changes that you describe--all affected Ada >> files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a >> (normal) build here but I have succeeded in doing my own private >> build >> in my own development system (which bypasses all of the PLplot build >> stuff) so I know the Ada code is OK. I hope you can make the changes >> at your end because I suspect that otherwise the build will fail >> (unless the ada.cmake edit overrides all new evil). > > Thanks, Jerry. Despite your concern, the build and test continue to > work fine after your changes. For example, on Linux "make > test_diff_psc" produces this result: > > ada > Missing examples : > Differing postscript output : > Missing stdout : > Differing stdout : adathick > Missing examples : > Differing postscript output : > Missing stdout : > Differing stdout : > > The reason why it works is you have simply removed all configurable > @whatever@ strings from the Ada files, but CMake configures those > files > anyway as a pure copy of the template file. And then the build and > test proceeds as normal using those copied files as source. > > I will now strip out all this configuration machinery so that the > template files are treated directly as source files with no need to > copy them. A beneficial side benefit of that change is I will be able > to rename all of them without the .cmake suffix. > > This strip out will take some time and care, but I hope to finish it > (with > similar good test results as above) by late today. > > Alan > __________________________ > Alan W. Irwin > Good to hear. I'll check out the problem with adathick but possibly not for 2-3 weeks as I'm planning to be away for a while. Jerry > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-07-23 06:14:30
|
On 2010-07-22 14:29-0700 Jerry wrote: > > On Jul 22, 2010, at 10:07 AM, Alan W. Irwin wrote: > >> I will now strip out all this configuration machinery so that the >> template files are treated directly as source files with no need to >> copy them. A beneficial side benefit of that change is I will be able >> to rename all of them without the .cmake suffix. >> >> This strip out will take some time and care, but I hope to finish it >> (with >> similar good test results as above) by late today. DONE as of revision 11101. > Good to hear. I'll check out the problem with adathick but possibly > not for 2-3 weeks as I'm planning to be away for a while. Actually, there is no problem with adathick (except that something in our mailpath wrapped the text summarizing the perfect test results in a funny way that lead you to believe there was an adathick error). So that leaves two remaining issues from this mini-project which I hope you will deal with after your break. (1) The documentation needs updating consistent with these changes. >From my previous post on this issue: <quote> software@raven> find -type f |grep -v .svn| \ grep -v '~$' |xargs grep -l HAVE_ADA_2007 ./doc/docbook/src/ada.xml ./bindings/ada/README.rtf ./bindings/ada/README ./cmake/modules/ada.cmake All of those except ada.cmake are documentation. </quote> (2) Please try the PLplot build and test system with Ada to make sure it works for you on Mac OS X. You mentioned you were currently using some specialized build system instead, but that doesn't help us find PLplot build-system issues for the combination of Ada and Mac OS X (if those exist) and also doesn't allow you to run our usual Ada-related tests on Mac OS X. Thus, I hope you are willing to keep trying the PLplot build and test system with Ada on Mac OS X and reporting back any issues you encounter. My impression is we don't have that many testers of the Ada bindings and examples for PLplot on Mac OS X, and that platform has a large number of configuration possibilities in any case considering all the fink and macport possibilities as well as the various possibilities for official Mac APIs (cocoa, carbon, etc.) so we need every tester we can get for that platform especially for less popular languages like Ada. For the same reasons I would appreciate others here with access to Mac OS X to always include Ada in their tests (especially after such a comprehensive change as the current one which touched virtually all Ada files). 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-07-24 00:45:22
|
On Jul 22, 2010, at 11:16 PM, Alan W. Irwin wrote: > On 2010-07-22 14:29-0700 Jerry wrote: > >> >> On Jul 22, 2010, at 10:07 AM, Alan W. Irwin wrote: >> >>> I will now strip out all this configuration machinery so that the >>> template files are treated directly as source files with no need to >>> copy them. A beneficial side benefit of that change is I will be >>> able >>> to rename all of them without the .cmake suffix. >>> >>> This strip out will take some time and care, but I hope to finish it >>> (with >>> similar good test results as above) by late today. > > DONE as of revision 11101. > >> Good to hear. I'll check out the problem with adathick but possibly >> not for 2-3 weeks as I'm planning to be away for a while. > > Actually, there is no problem with adathick (except that something in > our mailpath wrapped the text summarizing the perfect test results in > a funny way that lead you to believe there was an adathick error). > > So that leaves two remaining issues from this mini-project which I > hope > you will deal with after your break. > > (1) The documentation needs updating consistent with these changes. > From my previous post on this issue: > > <quote> > software@raven> find -type f |grep -v .svn| \ > grep -v '~$' |xargs grep -l HAVE_ADA_2007 > ./doc/docbook/src/ada.xml > ./bindings/ada/README.rtf > ./bindings/ada/README > ./cmake/modules/ada.cmake Indeed it needs updating. And I'll remove some of the docs in / bindings/ada/ because everything that is there is also now (and for quite a while) in the main docs where it is updated better. > > All of those except ada.cmake are documentation. > </quote> > > (2) Please try the PLplot build and test system with Ada to make sure > it works for you on Mac OS X. You mentioned you were currently using > some specialized build system instead, but that doesn't help us find > PLplot build-system issues for the combination of Ada and Mac OS X (if > those exist) and also doesn't allow you to run our usual Ada-related > tests on Mac OS X. Thus, I hope you are willing to keep trying the > PLplot build and test system with Ada on Mac OS X and reporting back > any issues you encounter. My impression is we don't have that many > testers of the Ada bindings and examples for PLplot on Mac OS X, and > that platform has a large number of configuration possibilities in any > case considering all the fink and macport possibilities as well as the > various possibilities for official Mac APIs (cocoa, carbon, etc.) so > we need every tester we can get for that platform especially for less > popular languages like Ada. I do normal PLplot builds fairly often and always before I commit changes. I just now did a sucessful build so everything looks good here. Jerry > > For the same reasons I would appreciate others here with access to Mac > OS X to always include Ada in their tests (especially after such a > comprehensive change as the current one which touched virtually all > Ada files). > > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-07-24 02:09:33
|
On 2010-07-23 17:44-0700 Jerry wrote: > I do normal PLplot builds fairly often and always before I commit > changes. I just now did a sucessful build so everything looks good here [with Ada]. Excellent! 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-09-08 02:49:39
|
On Jul 22, 2010, at 4:09 AM, Jerry wrote: > > On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: > >> On 2010-07-13 09:47-0600 Orion Poplawski wrote: >> >>> On 07/13/2010 01:21 AM, Alan W. Irwin wrote: >>>> I think very little effort would be required to remove >>>> HAVE_ADA_2007 >>>> from the build system. However, let's wait to do anything about >>>> this >>>> until we understand the linking issue that Orion reported a lot >>>> more. >>>> I still think the linking issue may be completely orthogonal to >>>> HAVE_ADA_2007. You imply above, that lapack/blas are not used by >>>> HAVE_ADA_2007 so it appears to me that Orion's discovery of a >>>> lapack/blas linking issue must be completely independent of >>>> HAVE_ADA_2007. >>> >>> Nope, if I turn HAVE_ADA_2007 off, it compiles fine. >> >> Thanks, Orion, for that clarification. >> >> The rest of this is principally directed to Jerry. >> >> Jerry, given that clarification does that firm up your idea of >> removing HAVE_ADA_2007 because the benefit is rather small for the >> cost of the the extra lapack/blas dependencies? >> >> The rest of this assumes you want to make that change. >> As far as the build system is concerned, all you have to >> do to completely disable HAVE_ADA_2007 is to replace >> >> option(HAVE_ADA_2007 "Ada 2007?" OFF) >> >> with >> >> set(HAVE_ADA_2007 OFF CACHE BOOL "Ada 2007?" FORCE) >> >> in cmake/modules/ada.cmake. The effect of that last command is to >> force >> the OFF value regardless of what the user attempts to set. >> After that, at your leisure, you can remove any HAVE_ADA_2007 >> configuration dependencies in the bindings and examples and also >> in the build system. >> >> To help you with that effort, here are the current places where >> HAVE_ADA_2007 shows up in our source tree. >> >> software@raven> find -type f |grep -v .svn| \ >> grep -v '~$' |xargs grep -l HAVE_ADA_2007 >> ./doc/docbook/src/ada.xml >> ./bindings/ada/README.rtf >> ./bindings/ada/README >> ./cmake/modules/ada.cmake >> >> All of those except ada.cmake are documentation. Looking at that >> file further, it sets Ada_Is_2007_With_and_Use_Numerics if >> HAVE_ADA_2007 >> is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. >> >> Those variables show up in the following places in our source tree : >> >> software@raven> find -type f | grep -v .svn | grep -v '~$' | \ >> xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort >> ./bindings/ada/plplot.adb.cmake >> ./bindings/ada/plplot.ads.cmake >> ./bindings/ada/plplot_auxiliary.ads.cmake >> ./bindings/ada/plplot_thin.ads.cmake >> ./bindings/ada/plplot_traditional.adb.cmake >> ./bindings/ada/plplot_traditional.ads.cmake >> ./cmake/modules/ada.cmake >> ./examples/ada/x01a.adb.cmake >> .... >> ./examples/ada/x31a.adb.cmake >> ./examples/ada/xthick01a.adb.cmake >> .... >> ./examples/ada/xthick31a.adb.cmake >> >> software@raven> find -type f | grep -v .svn | grep -v '~$' | \ >> xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort >> ./bindings/ada/plplot_auxiliary.ads.cmake >> ./cmake/modules/ada.cmake >> >> I would advise editing all the above *.cmake files to get rid of the >> references to the variables Ada_Is_2007_With_and_Use_Numerics >> Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is >> completed and you have tested it works then you should commit those >> changes. >> >> After that commit I can take over and do the necessary further >> changes >> to make those files non-configurable (from the CMake point of view), >> rename them without the *.cmake index in such a way that we do not >> lose svn history of those files, and commit all those further changes >> in such a way that we don't temporarily break PLplot. (That last >> issue >> has recently become important since we are using bisect methods to >> find regressions more and more, and commits that break PLplot >> interfere with that process unless you laboriously identify all such >> commits to the svn-bisect software.) >> >> Alan >> __________________________ >> Alan W. Irwin >> > > Alan, > > I have just committed the changes that you describe--all affected Ada > files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a > (normal) build here but I have succeeded in doing my own private build > in my own development system (which bypasses all of the PLplot build > stuff) so I know the Ada code is OK. I hope you can make the changes > at your end because I suspect that otherwise the build will fail > (unless the ada.cmake edit overrides all new evil). > > Jerry > > I suppose I should update this slightly old thread. I have made changes to the documentation and added suitable comments to the Ada code but I suppose I shouldn't assume that anyone has read it yet. The problem, in part, arose from some difficulty with at least some Linux distros having trouble linking to BLAS and LAPACK. (There has recently been someone else commenting on comp.lang.ada in a non-PLplot context of similar problems.) I then decided that it probably wasn't worth the hassle to link to those Ada 2005 specific libraries anyway since only two type declarations were being used. I then inserted my own versions of those declarations so that all Ada builds now should work without complaining about blas and lapack since they are never invoked. However, the effect on the user program in some cases will not be as benign as I first thought (my own included). The reason is a peculiarity of the Ada type system. Specifically, you can declare a type in one source file and declare the exact same type in another source file and Ada thinks they are different types and will not allow mixing them (without the user doing an explicit type conversion.) So even though I have provided equivalent declarations for Vectors and Matrices as is provided by Ada proper, they are incompatible. User programs that previously relied on the built-in declarations of Vector and Matrix _might_ now have a problem. Those Ada users and future Ada users have three choices in how they use PLplot: - Use it as-is and not rely on Ada-supplied Vector and Matrix declarations. - Make very minor edits to PLplot.auxiliary.ads and recompile _only_ the Ada bindings. (This is what I do.) Thus, the user can declare Vector and Matrix entities that are types of the "official" Ada types. - The user doesn't want to edit any PLplot code but wants to declare his/her own Vectors and Matrices using the "official" Ada types. In this case, do nothing to the source code but do type conversions of the user's Vector and Matrix entities to the PLplot Vector and Matrix types. This is sometimes an overlooked feature of Ada and probably incurs no run-time overhead. By the way, the GNAT GPL build recently released by Adacore for OS X 10.6, Snow Leopard, properly links to the BLAS and LAPACK frameworks by means of linker pragmas in i-forbla.adb. Specifically, that entire file is this: package body Interfaces.Fortran.BLAS is pragma Linker_Options ("-lgnala"); pragma Linker_Options ("-lm"); pragma Linker_Options ("-Wl,-framework,vecLib"); end Interfaces.Fortran.BLAS; On OS X, the BLAS and LAPACK libraries are in the vecLib framework. I would expect that something similar would work for Linux. Jerry |
From: Alan W. I. <ir...@be...> - 2010-09-08 04:45:10
|
Hi Jerry: On 2010-09-07 19:49-0700 Jerry wrote: > > User programs that previously relied on the built-in declarations of > Vector and Matrix _might_ now have a problem. >From my tests, I don't think the standard Ada (both thin and thick) examples are affected by this. Do those examples do something special to avoid the problem? If so, perhaps the documentation should advertise what that is (if it doesn't do that now). 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-09-09 06:50:06
|
On Sep 7, 2010, at 9:44 PM, Alan W. Irwin wrote: > Hi Jerry: > > On 2010-09-07 19:49-0700 Jerry wrote: > >> >> User programs that previously relied on the built-in declarations of >> Vector and Matrix _might_ now have a problem. > > From my tests, I don't think the standard Ada (both thin and thick) > examples are affected by this. Do those examples do something special > to avoid the problem? If so, perhaps the documentation should > advertise what that is (if it doesn't do that now). > > Alan > __________________________ No, they don't do anything special. All they do is reference the Vector and Matrix declarations which are in PLplot_auxiliary.ads and look like this: type Real_Vector is array (Integer range <>) of Long_Float; type Real_Matrix is array (Integer range <>, Integer range <>) of Long_Float; These are "open arrays" or in Ada, unconstrained arrays, indicated by <> instead of actual index ranges such as 3..7. The examples and any user program need only to reference the package which contains these. In Ada, this looks like with PLplot_Auxiliary; (and optionally,) use PLplot_Auxiliary; The examples or user program then needs to declare variables of these types with actual bounds specified. For example, in x01a.adb, there is this: xs, ys : Real_Vector (0 .. 5); but this is SOP for Ada. If, when the user begins writing his/her program and (1) knows that there will no use of the Ada 2005 numerical BLAS-LAPACK vector-matrix stuff (eigenthings, solvers, etc.) and (2) plans on using PLplot, then the Ada bindings will just work. This is how the Ada examples are written. However, if the user either (a) needs to use the numerical stuff in Ada or (b) begins writing the program using the "official" Ada declarations and realizes later that PLplot is needed, then he/she will need to either (*) comment two lines in PLplot_Auxiliary.adb and uncomment three lines, then recompile the Ada part and make sure the link to BLAS and LAPACK happens, or (+) insert an explicit type conversion when those "official" vectors and matrices are passed to PLplot. I have explained this in the documentation pretty much like this. By the way, this "easy switching" of declaration styles is the only remaining reason for keeping PLplot_Auxiliary.ad[bs] (some PLplot- specific utilities notwithstanding). I could eliminate it for all of Ada in PLplot but then it obscures how to do the "switch." It's a little ugly. I suppose other languages would do this with compiler pragmas but Ada does not have them--apparently someone thought they are unsafe. Jerry |