From: Tom K. <tom...@ve...> - 2013-12-31 18:01:55
|
Hi, I do not know if this is the right list for asking questions about the CMake Ada support from the Plplot modules. We are using the cmake modules that you have written in order to get our Ada code compiling/linking via cmake. But one of the things I have noted is that when gnatmake runs to build an Ada executable, -lstdc++ is added to the link line. We do not add this in our CMakeLists.txt files, so there is something about how CMake is calculating LINK_LIBRARIES, but I see nothing in the Ada support that would indicated -lstdc++ being added to LINK_LIBRARIES. Have you any idea? Thanks, Tom |
From: Alan W. I. <ir...@be...> - 2013-12-31 19:43:11
Attachments:
build_x02a.out.gz
|
On 2013-12-31 12:32-0500 Tom Kacvinsky wrote: > Hi, > > I do not know if this is the right list for asking questions about the > CMake Ada support from the Plplot modules. We are using the cmake modules > that you have written in order to get our Ada code compiling/linking via > cmake. But one of the things I have noted is that when gnatmake runs to > build an Ada executable, -lstdc++ is added to the link line. We do not add > this in our CMakeLists.txt files, so there is something about how CMake is > calculating LINK_LIBRARIES, but I see nothing in the Ada support that would > indicated -lstdc++ being added to LINK_LIBRARIES. Have you any idea? Hi Tom: Yes, this is the right place to ask questions about that Ada language support in CMake. However, note I wrote that some time ago, and at that time just followed what happens in the Fortran and C cases as a template with very little understanding of what goes on underneath by CMake and only superficial understanding of Ada and gnatmake. That said, this Ada language support works fine for us with the limitation that the user has to specify additional locations (e.g., of the *.ali files) to work around general CMake language support limitations. To answer your specific question, I cannot verify your report here; I have just built our Ada bindings and our second standard Ada example (to arbitrarily choose one of our ~30 standard examples) using make VERBOSE=1 x02a >& build_x02a.out (I have attached a compressed version of that output file for you to look at.) There is no mention of -lstdc++ in that file so I presume we are doing something differently than what PLplot does when building your Ada software. So you will want to take a look at our bindings/ada/CMakeLists.txt and examples/ada/CMakeLists.txt in the PLplot 5.9.11 tarball to see exactly how we use the Ada language support that is implemented in cmake/modules/language_support/cmake/ 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Tom K. <tom...@ve...> - 2014-01-03 15:12:18
|
Alan, Thanks. I think I figured out what is going on. For some reason, CMake adds its implicit C and C++ libraries (-lm and -lc, for C, -lstdc++, -lm, and -lc for C++) even though the language in use at the time is Ada. I've asked the on the CMake list how to get around this. It could be something we'll need to add to the Ada support modules. I don't know at this time, my questions to the CMake list have gone unanswered for quite some time now. Tom On Tue, Dec 31, 2013 at 2:43 PM, Alan W. Irwin <ir...@be...>wrote: > On 2013-12-31 12:32-0500 Tom Kacvinsky wrote: > > Hi, >> >> I do not know if this is the right list for asking questions about the >> CMake Ada support from the Plplot modules. We are using the cmake modules >> that you have written in order to get our Ada code compiling/linking via >> cmake. But one of the things I have noted is that when gnatmake runs to >> build an Ada executable, -lstdc++ is added to the link line. We do not >> add >> this in our CMakeLists.txt files, so there is something about how CMake is >> calculating LINK_LIBRARIES, but I see nothing in the Ada support that >> would >> indicated -lstdc++ being added to LINK_LIBRARIES. Have you any idea? >> > > Hi Tom: > > Yes, this is the right place to ask questions about that Ada language > support in CMake. However, note I wrote that some time ago, and at > that time just followed what happens in the Fortran and C cases as a > template with very little understanding of what goes on underneath by > CMake and only superficial understanding of Ada and gnatmake. That > said, this Ada language support works fine for us with the limitation > that the user has to specify additional locations (e.g., of the *.ali > files) to work around general CMake language support limitations. > > To answer your specific question, I cannot verify your report > here; I have just built our Ada bindings and our second > standard Ada example (to arbitrarily choose one of our ~30 standard > examples) using > > make VERBOSE=1 x02a >& build_x02a.out > > (I have attached a compressed version of that output file for you to > look at.) > > There is no mention of -lstdc++ in that file so I presume we are doing > something differently than what PLplot does when building your Ada > software. So you will want to take a look at our > bindings/ada/CMakeLists.txt and examples/ada/CMakeLists.txt in the > PLplot 5.9.11 tarball to see exactly how we use the Ada language > support that is implemented in cmake/modules/language_support/cmake/ > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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...> - 2014-01-03 18:20:46
|
On 2014-01-03 10:06-0500 Tom Kacvinsky wrote: > Alan, > > Thanks. I think I figured out what is going on. For some reason, CMake > adds its implicit C and C++ libraries (-lm and -lc, for C, -lstdc++, -lm, > and -lc for C++) even though the language in use at the time is Ada. I've > asked the on the CMake list how to get around this. [....] Hi Tom: I believe there is an important distinction which should be included in the above summary; the extra flags you refer to above all appear to occur for your project's CMake-based build system but not the PLplot one (as you can see from the file I attached earlier in this thread). Therefore, the issue is very likely in how your project's own CMake logic uses the Ada language support to build Ada executables. Some time ago I provided a self-contained and simple Ada test case (consisting of a "Hello World" Ada library and Ada executable that calls that library to print out that string). I maintain that simple test case in parallel with the equivalent PLplot build-system logic. Like PLplot but in a clearer way, that simple test case (which can be obtained by using svn to checkout http://svn.code.sf.net/p/plplot/code/branches/test_cmake/test_ada) shows how to properly use the Ada language support to build Ada libraries and Ada code that is linked to those libraries. If for that test case, you do not get the above extra flags, then clearly you should follow how that test case builds Ada libraries and executables in your own project's CMake-based build system to eliminate the problem. On the other hand, if for that test case you do generate the extraneous flags while that does not occur on my platform, then we probably have a case where your gnatmake is imposing those extra flags while mine does not, and you should be talking to the gnatmake developers instead. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Tom K. <tom...@ve...> - 2014-01-03 16:43:34
|
OK, here is what I have found: when building Ada executables, we link against two other libraries, one with C code, one with C++ code. CMake keeps track of this and adds implicit dependencies. Thus, when we link against the C++ built library, -lstdc++ comes along for the ride. I may be able to work around this configuration wise. But there may be nothing I can do about this if the implicit libraries cannot be overridden. Tom On Fri, Jan 3, 2014 at 10:06 AM, Tom Kacvinsky <tom...@ve... > wrote: > Alan, > > Thanks. I think I figured out what is going on. For some reason, CMake > adds its implicit C and C++ libraries (-lm and -lc, for C, -lstdc++, -lm, > and -lc for C++) even though the language in use at the time is Ada. I've > asked the on the CMake list how to get around this. It could be something > we'll need to add to the Ada support modules. I don't know at this time, > my questions to the CMake list have gone unanswered for quite some time now. > > Tom > > > On Tue, Dec 31, 2013 at 2:43 PM, Alan W. Irwin <ir...@be...>wrote: > >> On 2013-12-31 12:32-0500 Tom Kacvinsky wrote: >> >> Hi, >>> >>> I do not know if this is the right list for asking questions about the >>> CMake Ada support from the Plplot modules. We are using the cmake >>> modules >>> that you have written in order to get our Ada code compiling/linking via >>> cmake. But one of the things I have noted is that when gnatmake runs to >>> build an Ada executable, -lstdc++ is added to the link line. We do not >>> add >>> this in our CMakeLists.txt files, so there is something about how CMake >>> is >>> calculating LINK_LIBRARIES, but I see nothing in the Ada support that >>> would >>> indicated -lstdc++ being added to LINK_LIBRARIES. Have you any idea? >>> >> >> Hi Tom: >> >> Yes, this is the right place to ask questions about that Ada language >> support in CMake. However, note I wrote that some time ago, and at >> that time just followed what happens in the Fortran and C cases as a >> template with very little understanding of what goes on underneath by >> CMake and only superficial understanding of Ada and gnatmake. That >> said, this Ada language support works fine for us with the limitation >> that the user has to specify additional locations (e.g., of the *.ali >> files) to work around general CMake language support limitations. >> >> To answer your specific question, I cannot verify your report >> here; I have just built our Ada bindings and our second >> standard Ada example (to arbitrarily choose one of our ~30 standard >> examples) using >> >> make VERBOSE=1 x02a >& build_x02a.out >> >> (I have attached a compressed version of that output file for you to >> look at.) >> >> There is no mention of -lstdc++ in that file so I presume we are doing >> something differently than what PLplot does when building your Ada >> software. So you will want to take a look at our >> bindings/ada/CMakeLists.txt and examples/ada/CMakeLists.txt in the >> PLplot 5.9.11 tarball to see exactly how we use the Ada language >> support that is implemented in cmake/modules/language_support/cmake/ >> >> 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); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); 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...> - 2014-01-03 18:45:05
|
On 2014-01-03 11:43-0500 Tom Kacvinsky wrote: > OK, here is what I have found: when building Ada executables, we link > against two other libraries, one with C code, one with C++ code. CMake > keeps track of this and adds implicit dependencies. Thus, when we link > against the C++ built library, -lstdc++ comes along for the ride. Hi Tom: So it is a linking issue, and you can therefore largely ignore the post I just made. The simple cmake test case that I referred to in that post doesn't have the equivalent case of linking to a C library so if you try that case, you won't have these linking issues. However, our PLplot build system certainly does have an equivalent case; our principal Ada library (called libplplotadad) is linked to our principal C PLplot library (called libplplotd). To see how our principal Ada library is built by our build system logic look at bindings/ada/CMakeLists.txt within plplot-5.9.11.tar.gz. The resulting build steps are recorded in the build_x02a.out.gz file I attached previously. Look there for the following lines (without the e-mail wrapping issues). [100%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/HEAD/plplot_allura/bindings/ada/plplot.adb -o CMakeFiles/plplotadad.dir/plplot.o /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot_thin.o cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/HEAD/plplot_allura/bindings/ada/plplot_thin.adb -o CMakeFiles/plplotadad.dir/plplot_thin.o /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot_traditional.o cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/HEAD/plplot_allura/bindings/ada/plplot_traditional.adb -o CMakeFiles/plplotadad.dir/plplot_traditional.o /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot_auxiliary.o cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/HEAD/plplot_allura/bindings/ada/plplot_auxiliary.adb -o CMakeFiles/plplotadad.dir/plplot_auxiliary.o Linking Ada shared library libplplotadad.so cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && /home/software/cmake/install-2.8.12/bin/cmake -E cmake_link_script CMakeFiles/plplotadad.dir/link.txt --verbose=1 /usr/bin/gnatgcc -fPIC -shared -Wl,-soname,libplplotadad.so.1 -o libplplotadad.so.1.0.0 CMakeFiles/plplotadad.dir/plplot.o CMakeFiles/plplotadad.dir/plplot_thin.o CMakeFiles/plplotadad.dir/plplot_traditional.o CMakeFiles/plplotadad.dir/plplot_auxiliary.o ../../src/libplplotd.so.12.0.0 /usr/lib/x86_64-linux-gnu/libgnat.so -Wl,-rpath,/home/software/plplot_svn/HEAD/build_dir/src:/home/software/plplot_svn/HEAD/build_dir/lib/csa:/home/software/plplot_svn/HEAD/build_dir/lib/nn:/home/software/plplot_svn/HEAD/build_dir/lib/qsastime: -Wl,-rpath-link,/home/software/plplot_svn/HEAD/build_dir/lib/csa:/home/software/plplot_svn/HEAD/build_dir/lib/nn:/home/software/plplot_svn/HEAD/build_dir/lib/qsastime Clearly, there are no extra C library flags such as -lm or -lc. Therefore, I strongly suggest you should just copy what we do in bindings/ada/CMakeLists.txt, and that should likely solve the problem of the extra C++ library flags (such as -lstdc++) for your case where the linked library is written in C++ rather than C. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Tom K. <tom...@ve...> - 2014-01-03 20:15:30
|
There is one other difference between what PLPlot is doing and what we are doing. We are not making a shared library from Ada code, we are building an executable from Ada code. Even if we were making a shared library from Ada code, it is the fact we are linking in other static libraries built by CMake (so it can track implicit dependencies), not just .o files. I think that's what makes the difference. In any case, I was able to work around the problem by setting certain CMake variables and I am off on my way. Thanks again for the help. Tom On Fri, Jan 3, 2014 at 1:44 PM, Alan W. Irwin <ir...@be...>wrote: > On 2014-01-03 11:43-0500 Tom Kacvinsky wrote: > > OK, here is what I have found: when building Ada executables, we link >> against two other libraries, one with C code, one with C++ code. CMake >> keeps track of this and adds implicit dependencies. Thus, when we link >> against the C++ built library, -lstdc++ comes along for the ride. >> > > Hi Tom: > > So it is a linking issue, and you can therefore largely ignore > the post I just made. > > The simple cmake test case that I referred to in that post doesn't > have the equivalent case of linking to a C library so if you try that > case, you won't have these linking issues. However, our PLplot build > system certainly does have an equivalent case; our principal Ada > library (called libplplotadad) is linked to our principal C PLplot > library (called libplplotd). To see how our principal Ada library is > built by our build system logic look at bindings/ada/CMakeLists.txt > within plplot-5.9.11.tar.gz. The resulting build steps are recorded in > the build_x02a.out.gz file I attached previously. Look there for the > following lines (without the e-mail wrapping issues). > > [100%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o > cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && > /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/ > HEAD/plplot_allura/bindings/ada/plplot.adb -o CMakeFiles/plplotadad.dir/ > plplot.o > /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report > /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada > object bindings/ada/CMakeFiles/plplotadad.dir/plplot_thin.o > cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && > /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/ > HEAD/plplot_allura/bindings/ada/plplot_thin.adb -o > CMakeFiles/plplotadad.dir/plplot_thin.o > /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report > /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada > object bindings/ada/CMakeFiles/plplotadad.dir/plplot_traditional.o > cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && > /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/ > HEAD/plplot_allura/bindings/ada/plplot_traditional.adb -o > CMakeFiles/plplotadad.dir/plplot_traditional.o > /home/software/cmake/install-2.8.12/bin/cmake -E cmake_progress_report > /home/software/plplot_svn/HEAD/build_dir/CMakeFiles [100%] Building Ada > object bindings/ada/CMakeFiles/plplotadad.dir/plplot_auxiliary.o > cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && > /usr/bin/gnatgcc -fPIC -c /home/software/plplot_svn/ > HEAD/plplot_allura/bindings/ada/plplot_auxiliary.adb -o > CMakeFiles/plplotadad.dir/plplot_auxiliary.o > Linking Ada shared library libplplotadad.so > cd /home/software/plplot_svn/HEAD/build_dir/bindings/ada && > /home/software/cmake/install-2.8.12/bin/cmake -E cmake_link_script > CMakeFiles/plplotadad.dir/link.txt --verbose=1 > /usr/bin/gnatgcc -fPIC -shared -Wl,-soname,libplplotadad.so.1 -o > libplplotadad.so.1.0.0 CMakeFiles/plplotadad.dir/plplot.o > CMakeFiles/plplotadad.dir/plplot_thin.o CMakeFiles/plplotadad.dir/plplot_traditional.o > CMakeFiles/plplotadad.dir/plplot_auxiliary.o > ../../src/libplplotd.so.12.0.0 /usr/lib/x86_64-linux-gnu/libgnat.so > -Wl,-rpath,/home/software/plplot_svn/HEAD/build_dir/src: > /home/software/plplot_svn/HEAD/build_dir/lib/csa:/home/ > software/plplot_svn/HEAD/build_dir/lib/nn:/home/software/plplot_svn/HEAD/build_dir/lib/qsastime: > -Wl,-rpath-link,/home/software/plplot_svn/HEAD/build_dir/lib/csa:/home/ > software/plplot_svn/HEAD/build_dir/lib/nn:/home/software/plplot_svn/HEAD/ > build_dir/lib/qsastime > > Clearly, there are no extra C library flags such as -lm or -lc. > Therefore, I strongly suggest you should just copy what we do in > bindings/ada/CMakeLists.txt, and that should likely solve the problem > of the extra C++ library flags (such as -lstdc++) for your case where > the linked library is written in C++ rather than C. > > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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 > __________________________ > |