Does port:clang*'s libstdcxx have to be default?

[RJVB (René Bertin)]

Since a while the clang ports have a libstdcxx variant allowing to tell clang-mp* to use the libstdc++ provided by MacPorts.

That adds a dependency on gcc6, which I think is a rather significant and IMHO inacceptable large cost at the behest of what I think must be the needs of a relative minority of MacPorts users.

If I understand correctly the goal is just to add an option to the -stdlib argument (-stdlib=macports-libstdc++). I haven't tried this, but that option shouldn't require port:libgcc (sic!) as a runtime dependency (sic!) to be installed. After all, stock clang should already support -stdlib=libstdc++, and the port doesn't impose a gcc dependency for that. Rather, a build with that option will simply fail if no libstdc++ is present.

I know that -stdlib=libstdc++ does more than adding -lstdc++ to the linker options but IMHO it should be treated the same as far as compiler port dependencies are concerned. If some port requires using libstdc++ and needs to invoke clang with -stdlib=macports-libstdc++ it should also take care to add port:libgcc to its dependencies.

[jmroot (Joshua Root)]

I gather that this is in support of the cxx11 portgroup. It looks like the variant does not need to be default on platforms that default to libc++, at least.

[RJVB (René Bertin)]

Indeed, but the actual underlying question is probably "does the variant require an additional dependency".

Annoyingly I didn't think of that when I built clang 4.0.1 the other day, and cleaned out the workdir when everything worked. I'd test this myself but don't really feel like stressing my poor old MBP for almost 2h again just for this.

[kencu (Ken)]

the cxx11 1.1 portgroup requires this to work, as raimue said. it could be spec'd to be a default on only < 10.9 . the variant does need libgcc to be installed at runtime as it uses those headers and libs to function.

[raimue (Rainer Müller)]

I agree with René that the cxx11 port group should add the dependency on gcc6/libgcc instead of forcing everyone to install these ports when installing clang.

As far as I see the +libstdcxx variant only adds additional search paths to the clang compiler to support -stdlib=macports-libstdc++. clang will not link or need any files from the gcc ports unless this option is specified.

[raimue (Rainer Müller)]

See attached patch. However, I guess we need to rev-bump all orts using the cxx11 port group, as this might change the dependencies. It might be easier to move to increase the version of the port group instead.

[RJVB (René Bertin)]

Just to add another thing to consider for those who need extra convincing: it's a bit curious that installing clang also causes gcc to be installed.

However, I guess we need to rev-bump all orts using the cxx11 port group, as this might change the dependencies.

Would it? I don't think there's a big risk that libgcc will be uninstalled automatically just because of this change. It'd be nice too to revbump only the ports that set configure.cxx_stdlib to libstdc++ (use -libstdc=macports-libstdc++).

FWIW, your patch should probably do this to keep overhead lowest:

    depends_build-append port:gcc6
    depends_lib-append port:libgcc

Come to think of it: port:gccN is required here only because of the C++ headers. Those could (probably) very well be moved to port:libgcc, which would remove the need for depending on the full gcc package.

BTW, is there a patch that makes gcc accept -stdlib=macports-libstdc++, or should that argument really only be set when using clang?

(It probably also be a good idea if there were a gcc PG, to avoid having to hardcode the current default gcc port "everywhere".)

[kencu (Ken)]

revbumping all the cxx11 1.1 PortGroup ports would certainly use up some amps around the world.

[jeremyhu (Jeremy Huddleston Sequoia)]

If you remove the gcc / libgcc dependency from the llvm ports and move it to that PortGroup, I'm happy folding in the variant. The main point of the variant is to give people a way to remove that extra dependency. Don't forget to make the same change to llvm-3.9, llvm-4.0, llvm-5.0, and llvm-devel.

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, if you do bump llvm-3.9 and llvm-4.0 for this, please roll in the llvm-bin changes from be6401d19706f7317979dfbd680592cee5f7cf9d, so we can do both changes with a single revbump.

[RJVB (René Bertin)]

the llvm-bin changes from be6401d19706f7317979dfbd680592cee5f7cf9d

That doesn't seem to be in a MacPorts repository?

Out of curiosity, is there software that requires libstdc++ instead of libc++ on 10.9 and up?

[jmroot (Joshua Root)]

Replying to RJVB:

the llvm-bin changes from be6401d19706f7317979dfbd680592cee5f7cf9d

That doesn't seem to be in a MacPorts repository?

There are multiple repositories, so one needs to be specified for linking to work: [be6401d19706f7317979dfbd680592cee5f7cf9d/macports-ports]

[jmroot (Joshua Root)]

Replying to raimue:

See attached patch. However, I guess we need to rev-bump all orts using the cxx11 port group, as this might change the dependencies. It might be easier to move to increase the version of the port group instead.

The portgroup so far has only added a depends_build, so if there should have been a depends_lib then they're all incorrect anyway.

[RJVB (René Bertin)]

Replying to jmroot:

There are multiple repositories, so one needs to be specified for linking to work: [be6401d19706f7317979dfbd680592cee5f7cf9d/macports-ports]

I thought it'd be that one. I also thought I'd left a question on that page. Off-topic here but I don't get that change: I'm more used to removing proxying through xcrun to make it possible to use other compilers than AppleClang. Maybe this targets newer OS versions (than my 10.9)?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

I thought it'd be that one. I also thought I'd left a question on that page. Off-topic here but I don't get that change: I'm more used to removing proxying through xcrun to make it possible to use other compilers than AppleClang. Maybe this targets newer OS versions (than my 10.9)?

Following up in email on macports-dev instead of here.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I am fine not forcing the installation of GCC with Clang unless absolutely necessary.
There are a few things, however, that I need to look into before making the change.

1. If GCC is not installed, does -stdlib=macports-libstdc++ cause a compile-time error or silently do the wrong thing?
2. To avoid multiple recompilations of clang, can -stdlib=macports-libstdc++ now use gcc7 header files?
3. To avoid multiple recompilations of clang, add ​xcrun.

It might be a few days before I can look into these.

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

There are a few things, however, that I need to look into before making the change.

1. If GCC is not installed, does -stdlib=macports-libstdc++ cause a compile-time error or silently do the wrong thing?

As far as I can tell your patch uses a hardcoded full path to the MacPorts libstdc++ . That should fail if the library isn't there. Should be quick and easy to test (just move the MacPorts libstdc++.6.dylib file aside or deactivate port:libgcc).

1. To avoid multiple recompilations of clang, can -stdlib=macports-libstdc++ now use gcc7 header files?

It looks like gcc7 was finally bumped to the current 7.2 release which means that libgcc is now also at 7.2.0 . I think that means you *have* to use those.

Let me reiterate my suggestion to move the libstdc++ headerfiles into libgcc - what do you think Jeremy? At the very least port:libgcc could install a symlink to where the headerfiles ought to be installed

That's a separate ticket of course and shouldn't require clang rebuilds. I can try to look into that as part of my tinkering with the gcc7 port.

[jeremyhu (Jeremy Huddleston Sequoia)]

move the libstdc++ headerfiles into libgcc

Works for me.

[RJVB (René Bertin)]

Turns out to be relatively trivial (for the "real" port:libgcc, haven't looked into making the same mod to all the port:libgccN subports but see no reason they'd be any different). See #54773 .

[jeremyhu (Jeremy Huddleston Sequoia)]

The libgccXXX ports aren't relevant as they aren't for C++.

[mouse07410 (Mouse)]

Also, shouldn't the dependency (whether it's needed or not is another question) be on libgcc instead of libgcc6? Among other reasons, to allow pairing clang-5 with gcc7 instead of having to keep both gcc7 and gcc6 (thanks to explicitly specified libgcc6)?

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes Mouse, that's exactly the discussion happening in this ticket... having the libgcc port install the C++ headers, and moving the dependency into the c++11 port group.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 95ca160cf4f77eb4fbf7f8092e65eb5c3ebd21f3/macports-ports:

llvm-3.9 and llvm-4.0: use xcrun to spawn tools

See #54766#comment:12
See be6401d19706f7317979dfbd680592cee5f7cf9d/macports-ports

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In c79d736b4cc51f1f9fbea598382ef4960f05b316/macports-ports:

clang-*, gcc7: remove libgcc as a clang dependency

• libgcc installs GCC c++ header files.
• clang++-mp-* -stdlib=macports-libstdc++ looks for libgcc first.
  • If libgcc is installed, it is used.
  • If libgcc is NOT installed, the system libstdc++ is used.

See #54773
Fixes #54766

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 9aecd3399403a74145c89aecff6b18b3894f390f/macports-ports:

libgcc-devel: install GCC c++ header files

See #54766
See c79d736b4cc51f1f9fbea598382ef4960f05b316/macports-ports