libraw libstdc++ advice please
jmr at macports.org
Mon Nov 11 21:59:19 UTC 2019
On 2019-11-12 07:24 , Ken Cunningham wrote:
> while tracking down an openmp issue in ImageMagick that appears to have
> been due to fopenmp flags in libraw
> <https://trac.macports.org/ticket/59610> , we stumbled across the fact
> that libraw had a hard link to libstdc++ in it’s pkgconfig files. I
> removed that while doing other things, thinking it was just bitrot from
> the last decade, as the proper c++ standard library is selected by the
> cxx compiler.
> But the libraw dev says that even when building C code, libraw indeed
> needs to link against a c++ standard library for a few functions
> <https://github.com/LibRaw/LibRaw/issues/248> so that’s why it has the
> hardcoded link.
> So that will not automatically be done by clang when building C code, of
> To my moderate surprise, I see Catalina still has /usr/lib/libstdc++.dylib
> So the question:
> reinstate libraw’s hard link against libstdc++.dylib and move on, OR
> set the pkgconfig files to link against the configure.cxx_stdlib at the
> time libraw is being installed (and hope that works out for whatever is
> building something that is using the libraw pkgconfig files).
> Or some better idea?
>From the issue comments it sounds like the developer is saying that the
C++ stdlib is needed in the case of statically linking to libraw, which
is correct since libraw itself is C++. But (a) libs needed only when
linking statically should go in Libs.private in the .pc files, not Libs,
and (b) we aren't linking the example executables statically, so we
don't want them overlinked to the C++ stdlib.
I'm not sure it's possible to find out which C++ stdlib is being used in
a portable way. But that information is needed if upstream wants to
correctly insert it into the static link flags for dependents automatically.
More information about the macports-dev