port:libgcc/port:gcc7: proposed modifications, efficiency + libc++ support

[RJVB (René Bertin)]

This ticket contains 2 patches that introduce a few modifications I've already submitted before in a ticket that has gone stale. FWIW, the changes look impressive in a unified diff, but they're really mostly indentation and a few extra if/else statements.

Patchfile gcc7-libgcc.diff:

• moves the C++ headerfiles into port:libgcc, and adds a symlink so they can be accessed via a version-independent path ($prefix/include/gcc/c++).
  This change means clang doesn't need to depend on a full gcc port to use -stdlib=macports-libstdc++
• for those installing from source: adds a +with_libgcc variant to the main port and an automatic accompanying +stub variant to port:libgcc .
  The effect is simple: with these variants port:gcc7 will do a full install and libgcc becomes a simple stub so it can continue to be used as a 3rd party dependency. Users building from source will no longer need to build a good part of gcc twice, for the others nothing changes.
• an unrelated minor change: make GCC invoke the clang assembler as discussed in #54771.

Patchfile gcc7-libgcc+libcxx.diff:

All of the above, plus a set of +libcxx variants which configure g++ to use libc++ and its associated headerfiles. These can be either taken from port:clang (3.9, 4.0 or 5.0) or from Xcode. Currently this is a hardwired modification; until now it has worked for everything I've tried to build with it (including a complex project like digiKam). Done properly (adding a -stdlib argument to the gcc driver) it will stand a good chance to be upstreamed but I'd like to give this a bit more real-world testing before I delve further into the gcc code base. (Target gcc8 for upstreaming?)

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm not a fan of the +with_libgcc bits:

1. I'd rather someone that can read GPL3 figure out how to modify the build system to avoid the duplicated building.
2. The dylib ids are incorrect. It looks like you leave them with the versioned path which defeats one of the main points of the libgcc port. You should still have the actual files installed into libgcc with appropriate dylib ids and have gcc7 symlink those.

For the +libcxx changes... is g++ expected to be compatible with libc++? I'd rather not do something like that unless FSF or llvm sign up for that level of support.

[jeremyhu (Jeremy Huddleston Sequoia)]

For the assembler issue, the problem is that MacPorts doesn't allow us to solve it easily. Ideally, the cctools port would have a runtime dependency on a specific version of clang, which it would use for -q. However, llvm and clang ports require cctools at build time on older versions of macOS. There's no *real* dependency cycle there, but MacPorts sees one because we have no notion of dependencies that must be present at runtime but are not needed at build time.

We could solve this by providing a way to pass the path to clang to as. as/driver.c could support --clang= command line argument or just getenv("CLANG").

[RJVB (René Bertin)]

I don't understand your point 2, esp. not the point of incorrect dylib IDs. I'm not modifying those. Yes, the point of the +with_libgcc variant is to install gcc as one would normally do, and let port:libgcc install symlinks instead of actual library files, which point to the libraries installed by port:gcc7. That's enough to satisfy the dependencies of the binary builds provided by the build bots.

For the +libcxx changes... is g++ expected to be compatible with libc++?

Why would it not be, provided you use the correct headerfiles? My changes basically implement the instructions given on ​http://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc so there is some form of support for using libc++ with g++. In fact, I understand that libc++ aims to be a modern alternative to libstdc++, not something that is usable only with llvm.

I have asked on the GCC ML and it was confirmed that this change will also be considered for inclusion into gcc provided it doesn't hardcode the choice of runtime but adds a -stdlib option like clang has. I don't particularly mind trying to get that done properly before presenting the patch upstream (helping hands appreciated). But I'd really like to be able to argue that it has been tested by others before presenting it upstream.

[RJVB (René Bertin)]

Replying to jeremyhu:

For the assembler issue, the problem is that MacPorts doesn't allow us to solve it easily.

What issue? The fact that invoking cctool's as with the -q option doesn't give control over which clang it will use? I'm not sure if that's an actual issue. Calling as -q means you're using the command as a proxy so the actual work is done by an application that isn't part of the port. I cannot remember if I ever checked this but I wouldn't be surprised if as -q invokes the system clang. That would be in line with what $prefix/bin/gmake does: it too will invoke executables from the system toolchain unless told otherwise.

Control over the clang version could be nice but that's something that shouldn't have to be gcc's concern instead of cctools'.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

I don't understand your point 2, esp. not the point of incorrect dylib IDs. I'm not modifying those.

Exactly, that is the problem. You need to modify them and install them into the common path.

Instead, you're not modifying them and symlinking them from the common path.

Yes, the point of the +with_libgcc variant is to install gcc as one would normally do, and let port:libgcc install symlinks instead of actual library files, which point to the libraries installed by port:gcc7. That's enough to satisfy the dependencies of the binary builds provided by the build bots.

And them when you go and install gcc8+with_libgcc and uninstall gcc7, all the ports that link against those runtime libraries are then broken.

That is why you need to have the files in the common location and symlink them from the versioned paths.

For the +libcxx changes... is g++ expected to be compatible with libc++?

Why would it not be, provided you use the correct headerfiles? My changes basically implement the instructions given on ​http://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc so there is some form of support for using libc++ with g++. In fact, I understand that libc++ aims to be a modern alternative to libstdc++, not something that is usable only with llvm.

I have asked on the GCC ML and it was confirmed that this change will also be considered for inclusion into gcc provided it doesn't hardcode the choice of runtime but adds a -stdlib option like clang has. I don't particularly mind trying to get that done properly before presenting the patch upstream (helping hands appreciated). But I'd really like to be able to argue that it has been tested by others before presenting it upstream.

Well if that's the case, then I suppose that is fine. However, older versions of gcc might not be able to support required features for newer libc++, so be careful.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

Replying to jeremyhu:

For the assembler issue, the problem is that MacPorts doesn't allow us to solve it easily.

What issue?

depends_run are treated as build dependencies. Base does not allow a way to specify depends_run as a post-install/post-activate dependency.

The fact that invoking cctool's as with the -q option doesn't give control over which clang it will use?

I proposed a simple solution to that.

I'm not sure if that's an actual issue. Calling as -q means you're using the command as a proxy so the actual work is done by an application that isn't part of the port.

Yes.

I cannot remember if I ever checked this but I wouldn't be surprised if as -q invokes the system clang.

It invokes ${prefix}/bin/clang. See:

$ as -q
as: assembler (/opt/local/bin/clang) not installed

That would be in line with what $prefix/bin/gmake does: it too will invoke executables from the system toolchain unless told otherwise.

gmake doesn't have any logic in that regard. It sets up CC et al per spec and POSIX dictates how they are found via PATH.

Control over the clang version could be nice but that's something that shouldn't have to be gcc's concern instead of cctools'.

And that's exactly my point. cctools cannot depend on the clang ports and thus cannot specify what version of clang is used because MacPorts does not support the type of dependency needed here.

[RJVB (René Bertin)]

Replying to jeremyhu:

Replying to RJVB:

I don't understand your point 2, esp. not the point of incorrect dylib IDs. I'm not modifying those.

Exactly, that is the problem. You need to modify them and install them into the common path.

I see your point now. Fixing that shouldn't be too hard, just copy libgcc's post-destroot into gcc's (and just keep the headers in libgcc).

Your suggestion to modify the build system to build only libgcc is nice, but I don't see that happening. I'd have a try if this were using cmake but not with the current monstrosity combining autotools with a 3-step bootstrap procedure.

Well if that's the case, then I suppose that is fine. However, older versions of gcc might not be able to support required features for newer libc++, so be careful.

My first attempt at this was with gcc 6.3.0, which worked fine. I'm not planning on backporting it, but the code I'm patching is well preserved since several versions. I'll leave it to upstream to decide to which older versions this can be cherry-picked to when we get at that point.

And that's exactly my point. cctools cannot depend on the clang ports and thus cannot specify what version of clang is used because MacPorts does not support the type of dependency needed here.

If I understand correctly, cctools invokes something that is installed by port select. That's yet another layer of complexity. What I don't get is why it doesn't simply invoke clang. That will cause it to catch ${prefix}/bin/clang if it exists, but use the system compiler/assembler otherwise, thus doing exactly what make, cmake and family do.

Which frankly I think is preferable from a usability point of view. Being able to depend on a specific compiler version is nice for some things but most of the time it's just a PITA ...
...
Cf. port:libgcc ;)

[jeremyhu (Jeremy Huddleston Sequoia)]

What I don't get is why it doesn't simply invoke clang.

Because that's not what it's doing in as/driver.c. We can have it do whatever we want. I don't think searching $PATH for clang is good though because then we get nondeterministic behavior. We should have it envoke a fully qualified path or fail.

The purpose of port:libgcc is't about depending on specific compiler versions or not. It's about making sure that all the gcc compilers use the same (newest) runtime libraries to avoid pulling multiple copies into a single process.

[RJVB (René Bertin)]

Replying to jeremyhu:

What I don't get is why it doesn't simply invoke clang.

Because that's not what it's doing in as/driver.c. We can have it do whatever we want. I don't think searching $PATH for clang is good though because then we get nondeterministic behavior. We should have it envoke a fully qualified path or fail.

This should be discussed on a dedicated ticket, but I don't think the non-deterministic behaviour is a problem here. Even with a full path the behaviour remains nondeterministic, or if you want, without specifying a path as -q behaves just as deterministically as with ... user-deterministic. Meaning it's the user who decides what $prefix/bin/clang points to. I think that's fine in this case. And yes, I realise that /usr/bin/as -q invokes /usr/bin/clang but that's a bit different in that it can be expected to invoke the system clang specifically.

Making this an issue would basically mean that cmake, gmake and all ports shipping an IDE or software that can invoke a compiler would also have to provide variants that determines the default clang-mp. Instead we let those invoke their default compiler as clang or even cc and be done with it.

It would be somewhat different if as itself was being maintained, but from what I see it is basically an *old* GNU as that hasn't changed (much) since a long time. But even in that case as would be a different beast than clang.

On a related note, would making cctools depend on llvm_select make this any "cleaner"? I think it's the closest thing we have to a generic port:clang and at least it would give an indication that it might require files installed by port select.

The purpose of port:libgcc is't about depending on specific compiler versions or not. It's about making sure that all the gcc compilers use the same (newest) runtime libraries to avoid pulling multiple copies into a single process.

[jeremyhu (Jeremy Huddleston Sequoia)]

Making this an issue would basically mean that cmake, gmake and all ports shipping an IDE or software that can invoke a compiler would also have to provide variants that determines the default clang-mp

Nope. There's no reason for it to be done at that level. I'm saying you could change gcc (just like you are proposing with your patch) to include the full path. Eg:

#define ASM_OPTIONS "-q --clang=/opt/local/bin/clang-mp-5.0"

Then anyone using gcc would spawn 'as -q --clang=/opt/local/bin/clang-mp-5.0"

Alternatively, create a separate port that provides /opt/local/bin/clang-as and have that port depend on both cctools and a specific version of clang such that it just does:

#!/bin/sh
exec @@PREFIX@@/bin/as -q --clang=@@PREFIX@@/bin/clang-mp-@@CLANG_VERSION@@ "${@}"

Or we can breakup the cctools port into separate ports such that install_name_tool and as are provided by separate ports, allowing the llvm ports to depend on install_name_tool and the as port to depend on clang.

[RJVB (René Bertin)]

Well, I still don't agree but I already have llvmXX variants so I guess I don't care much either to use the first option.

Except that I hadn't really registered that as doesn't yet take a --clang argument. I'll take a raincheck on this aspect, until there is such an option. In the meantime we'll have to make do with a pre-fetch bail-out if ${prefix}/clang doesn't exist.

Edit: is there a hard reason why I shouldn't simply use /usr/bin/as -q or even the result from xcrun --find as at least when no +libcxx variant is selected? It feels a bit over the top to impose the installation of another complete compiler toolchain just to be able to use its assembler with an unrelated compiler.

[jeremyhu (Jeremy Huddleston Sequoia)]

is there a hard reason why I shouldn't simply use /usr/bin/as -q

Because that will only work well on Xcode 7 or 8 and newer.

what are those libgcc_ext.10.*.dylib "stub" libraries?

Newer compiler runtime functionality was available on 10.4 and 10.5. Those dylibs cause that functionality to be packed up by "our" libgcc_s.1.dylib given that it is not present on the host OS.

[RJVB (René Bertin)]

Replying to jeremyhu:

is there a hard reason why I shouldn't simply use /usr/bin/as -q

Because that will only work well on Xcode 7 or 8 and newer.

Care to give a bit more detail? My Xcode 6.something packs a clang 3.5 version and by the time you get around to replying I should have confirmation if gcc itself builds using that version for assembler or not.

Newer compiler runtime functionality was available on 10.4 and 10.5. Those dylibs cause that functionality to be packed up by "our" libgcc_s.1.dylib given that it is not present on the host OS.

Which is the earliest OS version this port builds on as it is currently anyway?

[RJVB (René Bertin)]

is there a hard reason why I shouldn't simply use /usr/bin/as -q

Because that will only work well on Xcode 7 or 8 and newer.

Care to give a bit more detail? My Xcode 6.something packs a clang 3.5 version and by the time you get around to replying I should have confirmation if gcc itself builds using that version for assembler or not.

Well indeed. GCC itself builds fine with the as from Xcode 6.2 (using a non-bootstrap build and the 10.9.5 system clang version). However, the resulting compiler failed to build some Qt 5.8 code (a bit surprising because that same code builds fine with the system clang).

EDIT: belay that. The failure I saw was due to using the c++/v1 headers from Xcode 6.2 . port:gcc7+libcxx40 (= using those headers from llvm-4.0) builds the problem code just fine, whether I use clang 4.0.1 as the assember or the system clang (600.0.57). With the latter the build is also about 10seconds faster (7-8%).

As a side-note: a full GCC build configured with --disable-bootstrap using clang-mp-4.0 is over 4x faster than the bootstrap-lean procedure used normally, the build directory is more than 2x smaller (*after* HFS compression!) and the resulting binary image (xz-compressed tarball) is 10% smaller. I still need to do a few comparisons of compiler performance (the bootstrapped version might be faster according to the docs) but these figures justify a +quick variant IMHO.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

Replying to jeremyhu:

is there a hard reason why I shouldn't simply use /usr/bin/as -q

Because that will only work well on Xcode 7 or 8 and newer.

Care to give a bit more detail? My Xcode 6.something packs a clang 3.5 version and by the time you get around to replying I should have confirmation if gcc itself builds using that version for assembler or not.

Ok, then maybe it is for Xcode 6 and newer. In any event, this functionality is pretty recent and definitely won't work with older tools.

Newer compiler runtime functionality was available on 10.4 and 10.5. Those dylibs cause that functionality to be packed up by "our" libgcc_s.1.dylib given that it is not present on the host OS.

Which is the earliest OS version this port builds on as it is currently anyway?

That question is not relevant here. You are confusing the version of the OS that you are running on versus the version of the OS that you are using the tools to build for. These libraries are used when using a deployment target older than 10.6 (even when building on much newer OS versions).

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

but these figures justify a +quick variant IMHO.

I suggest only rolling it out to gcc8 after you're done testing it. That should be an appropriate audience to help find issues.

[RJVB (René Bertin)]

Is it still possible to target 10.5 or 10.4 from, say, 10.9? I presume you'd need the corresponding SDKs, can you just copy them over?

I'm going to prepare updated patches. They'll look even more complex because I've been moving more things around in an effort to improve maintainability and upgrading.

I'll start giving port:gcc8 the same makeover but I can't promise I'll be doing a lot of testing with a beta compiler. I have no idea what new amazing features gcc8 introduces but unless there's something we never knew we wanted in there I would expect the gcc7 audience to be larger and just as entitled to improvements as those living on the bleeding edge.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

Is it still possible to target 10.5 or 10.4 from, say, 10.9?

Yes, quite possible.

I presume you'd need the corresponding SDKs, can you just copy them over?

No, you can use the current SDK to target older OS versions. The SDKs contain availability annotation such that functionality that is newer than the deployment target is weakly linked instead of strongly linked.

I'm going to prepare updated patches. They'll look even more complex because I've been moving more things around in an effort to improve maintainability and upgrading.

I'll start giving port:gcc8 the same makeover but I can't promise I'll be doing a lot of testing with a beta compiler. I have no idea what new amazing features gcc8 introduces but unless there's something we never knew we wanted in there I would expect the gcc7 audience to be larger and just as entitled to improvements as those living on the bleeding edge.

gcc7 should really only get changes after they've landed in gcc8. Just do your testing against the gcc7 port and then apply the diff to gcc8. They're basically identical.

How do you intend to handle conflicts between gcc7 and gcc8-provided libgcc in your variant scheme?

[kencu (Ken)]

Replying to RJVB:

Is it still possible to target 10.5 or 10.4 from, say, 10.9? I presume you'd need the corresponding SDKs, can you just copy them over?

You might be interested in taking a look at the work this MacPorts contributor has done in this regard <​https://github.com/devernay/xcodelegacy> as well.

[RJVB (René Bertin)]

Replying to jeremyhu:

gcc7 should really only get changes after they've landed in gcc8. Just do your testing against the gcc7 port and then apply the diff to gcc8. They're basically identical.

I was counting on the ports to be mostly similar, I also hope my changes can land at about the same time in both ports. Users interested in testing libc++ support should be able to do so with a release compiler.

How do you intend to handle conflicts between gcc7 and gcc8-provided libgcc in your variant scheme?

There shouldn't be any more conflicts than there are currently. Certainly not between the gcc7-provided libgcc and the gcc8-provided libgcc-devel as those ports conflict.

I have followed your suggestions about the install location for the runtime (libgcc) libraries. My port:gcc7+with_libgcc variant now also puts them into lib/libgcc, and port:libgcc+stub only puts a placeholder into that location. It took me some time to get changing the rpath in the libgcc_ext libraries right, but I found a way (ex to the rescue! :)) Why doesn't install_name_tool support changing that kind of stub library anyway?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

Replying to jeremyhu:

gcc7 should really only get changes after they've landed in gcc8. Just do your testing against the gcc7 port and then apply the diff to gcc8. They're basically identical.

I was counting on the ports to be mostly similar, I also hope my changes can land at about the same time in both ports. Users interested in testing libc++ support should be able to do so with a release compiler.

How do you intend to handle conflicts between gcc7 and gcc8-provided libgcc in your variant scheme?

There shouldn't be any more conflicts than there are currently. Certainly not between the gcc7-provided libgcc and the gcc8-provided libgcc-devel as those ports conflict.

As I see it, there are more conflicts than before:

libgcc-devel now conflicts with gcc7+with_libgcc for instance. gcc8+with_libgcc is conflicting with gcc+with_libgcc ... etc.

[RJVB (René Bertin)]

I would hope that gccX+with_libgcc and gccY+with_libgcc don't conflict (except currently for gcc7 and gcc8) because only one of them installs things into lib/libgcc . I admit I haven't yet given thought to this except in the back of my mind because at the moment conflicts are handled at the level of port:libgcc . You still need to install that port, I'll have another look if port:libgcc+stub really needs to depend on its corresponding port:gcc or if I can restore the opposite dependency.

I noticed another thing: back in 2013 you re-enabled the no-bootstrap build for libgcc, which was undone in 2015 when Ryan committed a new version. Was that a casualty or was there a solid reason for this? I'm currently trying a "full" libgcc build with --disable-bootstrap, from what I understand this should work on at least 10.8 and up.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to RJVB:

I would hope that gccX+with_libgcc and gccY+with_libgcc don't conflict (except currently for gcc7 and gcc8) because only one of them installs things into lib/libgcc

I'm confused. Why would only one of them install the gcc runtime libraries into lib/libgcc? Where would the other install the runtime? That doesn't really make sense to me. Both should be conflicting as they should both be providing the gcc runtime in lib/libgcc.

I noticed another thing: back in 2013 you re-enabled the no-bootstrap build for libgcc, which was undone in 2015 when Ryan committed a new version. Was that a casualty or was there a solid reason for this? I'm currently trying a "full" libgcc build with --disable-bootstrap, from what I understand this should work on at least 10.8 and up.

    # TODO: Possibly disable bootstrap with appropriate configure flags.
    #       the problem is that libstdc++'s configure script tests for tls support
    #       using the running compiler (not gcc for which libstdc++ is being built).
    #       Thus when we build with clang, we get a mismatch
    # http://trac.macports.org/ticket/36116
    #compiler.blacklist-append {clang < 425}
    #configure.args-append --disable-bootstrap
    #build.target        all

It should work with a deployment target of 10.7 and up as the system provided TLS natively in Lion. You can see this with:

$ echo '__thread int a;' | clang -x c -o /dev/null -c - -mmacosx-version-min=10.7

$ echo '__thread int a;' | clang -x c -o /dev/null -c - -mmacosx-version-min=10.6
<stdin>:1:1: error: thread-local storage is not supported for the current target
__thread int a;
^
1 error generated.

[RJVB (René Bertin)]

Replying to jeremyhu:

I'm confused. Why would only one of them install the gcc runtime libraries into lib/libgcc? Where would the other install the runtime? That doesn't really make sense to me. Both should be conflicting as they should both be providing the gcc runtime in lib/libgcc.

I must have been a bit confused too, under the assumption one could have libgcc6 installed in parallel to libgcc but that's clearly not the case.

I *thought* that the latest version I just uploaded avoided the whole issue because it doesn't change the dependency structure. port:gcc+with_libgcc still depends on port:libgcc . This is a surprisingly hard one to get my head around.

It's becoming clear to me that we probably shouldn't add a +with_libgcc variant to all gcc ports but only to the newest stable release (gcc7) and/or the next release (gcc8). I'll go back to the drawing board after a night's sleep and see how complex the code is going to be to declare the appropriate conflicts. The most elegant approach would be that gcc8 doesn't support the +with_libgcc variant if gcc7 is installed with it and vice versa.

Do we even know if port:gcc8 works with port:libgcc instead of port:libgcc-devel?

If this becomes too complex I'll drop the whole +with_libgcc idea. The "full" port:libgcc took 15 minutes to build, which is almost reasonable.

It should work with a deployment target of 10.7 and up as the system provided TLS natively in Lion. You can see this with:

Thanks. So I was a bit pessimistic with my (lazy) estimation that 10.8 was the earliest possible version where a non-bootstrap build would work.

[RJVB (René Bertin)]

Replying to RJVB:

The most elegant approach would be that gcc8 doesn't support the +with_libgcc variant if gcc7 is installed with it and vice versa.

That was actually quite easy to implement and not significantly different from what I was already doing to auto-activate the +stub variant when required. I think it's easier to see what's going on in my Portfile version from the actual file rather than a large unified diff:

​https://github.com/RJVB/macstrop/blob/master/lang/gcc7/Portfile#L352

That's the part where I determine if it's possible to install port:gcc7 +with_libgcc without causing runtime library conflicts in lib/libgcc . The code is written in such a way that it can be used unmodified in port:gcc7 and port:gcc8 (=> port:gcc8 and port:gcc9 in some future) and is based on the constraint that only the current latest stable release and beta/devel port versions can be installed with that variant. Those are the ports that are most likely to receive frequent upgrades. For the older versions (at least gcc6) we could only backport the bootstrap-less building as a gesture to users installing from source.

[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

[cjones051073 (Chris Jones)]

Gcc 10 and above now have support for building against libc++