gcc12 insists on clang13?!

[mouse07410 (Mouse)]

Please remove run-time dependency on clang13 in gcc12:

$ port info gcc12
gcc12 @12.1.0_1 (lang)
Sub-ports:            libgcc12
Variants:             [+]enable_stdlib_flag, universal

Description:          The GNU compiler collection, including front ends for C, C++, Objective-C, Objective-C++ and Fortran.
Homepage:             https://gcc.gnu.org/

Extract Dependencies: xz
Build Dependencies:   texinfo
Library Dependencies: cctools, gmp, isl, ld64, libiconv, libmpc, mpfr, zlib, zstd
Runtime Dependencies: gcc_select, libgcc, clang-13
Platforms:            darwin
License:              (GPL-3+ or Permissive)
Maintainers:          none

Must add that thankfully this seems to be the only gcc port version that exhibits this problem, e.g.:

$ port info gcc11
gcc11 @11.3.0_2 (lang)
Sub-ports:            libgcc11
Variants:             universal

Description:          The GNU compiler collection, including front ends for C, C++, Objective-C, Objective-C++ and Fortran.
Homepage:             https://gcc.gnu.org/

Extract Dependencies: xz
Build Dependencies:   texinfo
Library Dependencies: cctools, gmp, isl, ld64, libiconv, libmpc, mpfr, zlib, zstd
Runtime Dependencies: gcc_select, libgcc11
Platforms:            darwin
License:              (GPL-3+ or Permissive)
Maintainers:          none
$ 

[ryandesign (Ryan Carsten Schmidt)]

The clang13 dependency is added by the +enable_stdlib_flag variant (which is incidentally not a good variant name: we don't use variant names beginning with "enable"; it is self understood that all variants enable something). You can read the comments in the Portfile to find out why. If you don't want the clang13 dependency, you can deselect that variant, at the expense of having the build the port from source, of course.

[mouse07410 (Mouse)]

The clang13 dependency is added by the +enable_stdlib_flag variant

First, could you clarify what that means? What values can one specify for that flag?

This is from Xcode gcc (not Macports):

$ gcc --help
.  .  .
  -stdlib++-isystem <directory>
                          Use directory as the C++ standard library include path
  -stdlib=<value>         C++ standard library to use
.  .  .

This is from Macports gcc11 and gcc12:

$ gcc-mp-11 --help
.  .  .
  -specs=<file>            Override built-in specs with the contents of <file>.
  -std=<standard>          Assume that the input sources are for <standard>.
  --sysroot=<directory>    Use <directory> as the root directory for headers
                           and libraries.
  -B <directory>           Add <directory> to the compiler's search paths.
  -v                       Display the programs invoked by the compiler.
.  .  .
$ gcc-mp-12 --help
.  .  .
  -specs=<file>            Override built-in specs with the contents of <file>.
  -std=<standard>          Assume that the input sources are for <standard>.
  --sysroot=<directory>    Use <directory> as the root directory for headers
                           and libraries.
  -B <directory>           Add <directory> to the compiler's search paths.
  -v                       Display the programs invoked by the compiler.
.  .  .

No mentioning of -stdlib at all, let alone any hint what could/should be give there.

This is what "variants" say.

[+]enable_stdlib_flag: Enable stdlib command line flag to select c++ runtime

[kencu (Ken)]

There is no Xcode gcc.

[mouse07410 (Mouse)]

There is no Xcode gcc.

Except that Xcode includes an executable named "gcc", that reports on itself as clang ;-)

$ /usr/bin/gcc -v
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Could you educate me please: do I understand correctly that if I invoke G++ like g++ -stdlib=libc++, I can link the resulting binary with Clang++-produced libraries? Addressing a huge problem with g++ (had to have all of the involved libraries compiled by g++, or linking would fail)?

[kencu (Ken)]

It’s just a symlink to clang, for convenience.

It’s not gcc, which is why it says it’s clang

[cjones051073 (Chris Jones)]

Yes, gcc12 supports linking against the libc++ runtime. Thats what the -stdlib flag enables. See

​https://github.com/macports/macports-ports/pull/15295#issuecomment-1176477475

Regarding the variant name, y=yes, you are right I should have not started it with enable_. I'll remove but defer doing it to a future update as forcing yet another gcc build to do this seems unnecessary...

[cjones051073 (Chris Jones)]

Mouse - Use, with gcc12 if you build with -stdlib=libc++ the resulting binaries can in principle be inter-mixed with those created with clang++ as the runtime used is then the same.

I do agree its not ideal that gcc has a runtime dep on clang, but gcc does not ship its own libc++ so you have to point it at an external installation to enable the feature, and Xcode is not enough, I couldn't get it to work with that. Hence I just went with using one of the Macports installs., as then the additional benefit is all OSes get the same (although, note, they are still limited in what they actually can support by the system libc++, in the exact same way as the clang compilers are. But thats another issue for another day).

[mouse07410 (Mouse)]

@cjones051073 Having g++ support linking against libc++ in great in my opinion - I'm willing to pay the price of installing clang for that. How you name this variant - is less important, and IMHO it's perfectly OK to make it default. So please leave it as-is, maybe switching the dependency from clang-13 to clang-14.

Or better yet - can gcc12 (and subsequent) consider dependency on any installed Macports clang, say - newer than clang-12? That would be just perfect for me, as I always have Macports clang installed, usually the latest one released.

And perhaps adding a few words to the "variants" description would help people understand what good thing the new default is offering.

[cjones051073 (Chris Jones)]

Clang-14 has proved a little unstable - Its seen a number of bug fix releases and we have seen some issues with its use in Macports. For this reason clang-13 is still the default fallback for now.

[cjones051073 (Chris Jones)]

@mouse I first wanted to do exactly what you suggest, have gcc support using *any* available clang runtime. I couldn't get that to work though - the build has to be configured with a specific path

​https://github.com/macports/macports-ports/blob/4d2e8583176bad559b26c54c2ec4f8ef73c3238c/lang/gcc12/Portfile#L199

and the path given there is what will be used. The build also checks it 'works' before enabling the feature.

Maybe one possible change is to make the path there one provided by some new stub port livcxx-runtime or some such, that then just makes that path point to some specific runtime. That stub port could then maybe have variants to pick the clang version.

Note 100% sure its worth the complexity, but if someone was interested it could be done I guess...

[kencu (Ken)]

NB Marcus has had an open PR that allowed gcc to use the system’s headers for libc++ for some weeks now:

​https://github.com/macports/macports-ports/pull/14546

No doubt Chris you tried that and you couldn’t make it work, so you had to go eith the entire clang-13 install.

So might as well close Marcus’ PR then.

[cjones051073 (Chris Jones)]

Nope, I was unaware of that PR.

[mouse07410 (Mouse)]

Maybe one possible change is to make the path there one provided by some new stub port libcxx-runtime or some such, that then just makes that path point to some specific runtime. That stub port could then maybe have variants to pick the clang version.

This seems worth trying. Because the objective IMHO is to allow gcc12+ to use whatever (acceptable) clang that's installed, and/or let the user decide which clang to install.

Note 100% sure its worth the complexity, but if someone was interested it could be done I guess...

I can't tell if it's worth the complexity, as I can't evaluate how complex it's likely to be - but if you can afford to experiment with it, I'm sure at least some users would appreciate it, myself definitely included.

[kencu (Ken)]

working as designed