On Thu, May 21, 2015 at 06:31:00PM -0700, Alan Irwin wrote:
> 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.
Alan,
Sorry for the delay in replying, but I've been away and busy with work.
I agree with your conclusion that it is probably not worth it. If you did
want to implement this for g++ though, then the point about the multiple
directories is that you should link against the correct version of stdc++
for your gcc version. To find this the best way is probably to use the
-print-file-name option.
On my Ubuntu system
$ g++ -print-file-name=libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so
$ g++-4.4 -print-file-name=libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.4.7/libstdc++.so
So this will always pick up the right version. This should work across
multiple Linux distributions, and also, I hope, on cygwin etc.
Andrew
~
~
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
