Hi Andrew: I will respond to your two posts here.
On 2015-05-21 22:54+0100 Andrew Ross wrote: > > Alan, > > I think your summary is probably correct Good. That is a big relief to me that I wasn't missing anything obvious, and thanks for that review. > [B]ut the solution of just > explicitly linking stdc++ is so simple, that it makes me think it must be > possible to work round this. A flag if there is any C++ code would be > sufficient to identify the need to link with stdc++? More below on this after I quote your additional post. On 2015-05-21 23:00+0100 Andrew Ross wrote: > > I should probably add that this would for g++, but perhaps not other > compilers. This is a common enough case that it is perhaps worth > supporting as a special case nontheless? > > Or we could take the decision that cmake builds are the way to go, and we > can't support all non-standard cases for the traditional build. Even if you restrict yourself to supporting only the g++ compiler for this corner case, the problem is that even if you restrict yourself still further to just Debian wheezy, there are 3 separate libstdc++.so symbolic links depending on g++ compiler version, i.e., /usr/lib/gcc/x86_64-linux-gnu/4.4/libstdc++.so /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so As it happens they all link to the same version of the libstdc++.so.6 symlink for Debian wheezy, but in general I don't think you can guarantee that for all Linux platforms. And in any case the CMake find_library command works only for the *.so version of library symlinks and not the *.so.NNNN version of library symlinks. So you need a cross-platform way with whatever g++ version you are using to find the appropriate directory above in which to do the CMake find_library(stdc++). And when I attempted to implement that a few months back it turned into a real mess with semicolon separation of library locations turning into colon separation for the latest g++ version on Fedora. And I have no idea how the Cygwin version of g++ is going to cope with that "upgrade" since colon separation is also intrinsically obfuscated by the drive letter question. Therefore I deleted that whole mess of logic and moved to the compiling all our C code examples in the traditional build with C++ (which automatically brings in the correct version of libstdc++.so that is consistent with the compiler version). But obviously that general and elegant solution (to link with whatever C++ compiler is being used) is not available for other language examples such as Ada, D, f95, java, and ocaml. In principle, of course, it should be possible to discover the name and directory location of the special library (or libraries) associated with the C++ in a fairly general way. For example, on Unix (including Cygwin) you might be able to make a test compilation of a C++ executable with no content so it should not link to any regular libraries, analyze that with readelf or ldd to discover all special C++ compiler libraries it depends on, and add those libraries to the pkg-config files for our ada, d, f95, java, and ocaml bindings. And there is likely to be similar test cases you can invoke on Windows. But I have run out of mental energy to pursue something further like that just to give complete pkg-config results for the corner case. So I invite you or anybody else here who might be intrigued by that general idea or any other elegant solution to the problem to give it a go. But for now, I really think the right thing to do here is what I have done with commit a09dc18 which is simply to declare we are not going to attempt (at least at this time) to discover the name and location of the special library associated with the user's C++ compiler, put a warning to that effect in the configured Makefiles of the traditional build of the Ada, D, f95, java, and ocaml examples, and also avoid using those configured files for comprehensive testing if the prerequisites (static build of PLplot, any C++ device driver enabled, traditional build system for the installed examples) of this corner case are satisfied. (Note it is not as bad as it sounds because we don't have either java or ocaml bindings available in any case for a static build so we are only truly eliminating compiling and testing the Ada, D, and f95 examples for this corner case). 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 __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
