It can be problematic though, even when the two libstdc++.so files are
symlinks or otherwise identical. If you provide libstdc++.so in a "runtime
only" package, you don't want the compiler's location to be hardcoded. The
fix is to simply force a particular path with -L in LDFLAGS.
As I mentioned before though, it may be that a library your project depends
on that's actually hard coded the wrong path - Solaris ld will still
complain about what you're currently linking. I don't think PCRE depends
on anything else that is c++ though, so it's probably coming from libtool
adding something different.
I'm not really a fan of Libtool adding an explicit dependency for libstdc++
really. Libtool won't do this if you're using a different c++ compiler,
and the only case where this might help you out would be when your main
program isn't c++, and since Libtool doesn't help with this in that
situation, it probably shouldn't treat gcc as a special case.
> On Tue, 24 Apr 2012, Robert Boehne wrote:
>> Find out what the path for libstdc++.so is for the one you want,
>> then set LDFLAGS=-L/correct/path/ when you build the library that it's
>> complaining about.
>> Note that it may not be PCRE, but it could be something that PCRE links
>> Use "ldd" or "ldd -s" to find out which libraries are pulling in
>> libstdc++ and from where.
> I think that the situation is that when linking with the C++ compiler, the
> C++ compiler automatically adds linkage to its own libstdc++.so. Libtool
> also adds linkage to libstdc++.so (as a dependency) so the linker sees the
> (hopefully) same shared library listed twice. There would be a severe
> problem if libtool was to request linking with a different libstdc++.so
> than the C++ compiler needs.
> Solaris ld warns about this issue, and presumably GNU ld does not.
> Bob Friesenhahn
> bfriesen@simp..., http://www.simplesystems.org/**
> users/bfriesen/ <http://www.simplesystems.org/users/bfriesen/> > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >