Feedback on clang change (#53194)

Mojca Miklavec mojca at macports.org
Wed Feb 1 21:37:31 UTC 2017


On 1 February 2017 at 20:33, Marcus Calhoun-Lopez wrote:
>
>> Something that's not entirely clear to me yet is what's the benefit of
>> having clang compile software against gcc's libstdc++ vs. gcc6
>> compiling it.
>
> I have attempted to build both Qt and Octave with gcc6, and I have run across a few unpleasant incompatibilities.
>
> After trying to work around these problems for a time, I gave up.

Thank you.

So basically you need this to be able to compile binaries and
libraries against the same stdlib, where you need gcc6 for one and
clang for the other and the trick with D_GLIBCXX_USE_CXX11_ABI=0 is
not sufficient?

>> And what's the relation of all this to the magic
>> -D_GLIBCXX_USE_CXX11_ABI=0 flag.
> My point of reference: https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/manual/using_dual_abi.html
> The following code is what I wrote to test various combinations.
> The -D_GLIBCXX_USE_CXX11_ABI=0 forces the new libstdc++ string and list implementations to be compatible with the old libstdc++ string and list implementations.
>
> main.cxx:
>     #include "f1.hxx"
>     int main() { f1("Hi There"); }
>
> f1.hxx:
>     #include <string>
>     void f1(const std::string& string);
>
> f1.cxx
>     #include "f1.hxx"
>     #include <iostream>
>     void f1(const std::string& string) { std::cout << string << "\n"; }
>
> /opt/local/bin/g++-mp-6 -c -D_GLIBCXX_USE_CXX11_ABI=0 f1.cxx
> /usr/bin/clang++ -c -stdlib=libstdc++ -std=c++11 main.cxx
> /usr/bin/clang++ -stdlib=libstdc++ *.o
> ./a.out
> /opt/local/bin/g++-mp-6 *.o
> ./a.out

COOL!

That way I can put C++11 code to f1.cxx and use
    /usr/bin/clang++ -stdlib=libstdc++ *.o
to get the final binary built against
    /usr/lib/libstdc++.dylib

I don't think it's trivial to automatically build ports that way, but
I like the idea a lot.

So just to make sure: is this orthogonal to the current discussion?
That is: assuming you use
    clang++ -stdlib=macports-libstdc++ ...

What is then the situation with respect to compatibility? Does that
mean that binaries compiled with "clang++ -stdlib=macports-libstdc++"
will (only) be compatible with other libraries built with gcc6 (or
with the same method), but incompatible with binaries built against
libc++ and /usr/lib/libstdc++.dylib?

>>> I should have made clear that a major downside of choice #2 is that it requires a library dependency on gcc6.
>>
>> Thanks, I missed that. And I agree that this is a bit of a downside.
>> What kind of dependency is that exactly? Is it only a dependency
>> because the port needs to make sure that gcc's libstdc++ is present at
>> the time of compilation or are there some other more hardwired
>> constraints?
> When the patched clang is called, the header files of gcc6 are used and the libraries from libgcc are linked in.

But the libraries are only linked into the compiled binary, not into
clang, right?
And the header files are only used when maports-libstc++ is requested, I assume?

Are there any negative consequences if the user:
- installs clang (with support for macports-libstdc++)
- doesn't compile any binary against maports-libstc++
- uninstals libgcc
Would the compiler crash or stop working?

> After compilation, the libraries from libgcc have to be there for the resulting binary to run.

But that's also true for any given binary that gets compiled with
gcc6. And for any binary that gets compiled against libc++ on 10.6.
While I don't know if we currently handle that properly (I assume that
MacPorts won't complain if you compile a port with gcc6 and then
uninstall gcc6), I don't consider that to be a serious problem.

Perhaps some people would not like it if installing just clang
(without actually compiling any binary against gcc's libstdc++) would
depend on libgcc, I don't know. But I would also say that users of <
10.9 should not complain if one additional dependency on libgcc gets
pulled it.

With all that, having one special subport of just the latest clang
(with some special name) that would perhaps even compile against
libstdc++ by default doesn't sound such a bad idea either.

Mojca


More information about the macports-dev mailing list