gcc12/libgcc12: has made the @rpath transition happen, now we need to manage it

[kencu (Ken)]

As expected now that we have included Iain's latest patch in our default libgcc12 installation, the @rpath transition is upon us:

% otool -L /opt/local/lib/libgcc/libstdc++.6.dylib
/opt/local/lib/libgcc/libstdc++.6.dylib:
	@rpath/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.30.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	@rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

however, only two of our gcc ports, gcc12 and gcc-devel (on arm only) are using the extra piece that adds the needed rpath directory to the rpath search directory list.

So any ports that are newly built with any other version of gcc on systems newer than MacOS 10.11 will be broken, as they won't find the @rpath libraries.

We should update all our gcc versions (gcc10 and gcc11) on all systems to Iain's forks to fix them.

All other versions of gcc (gcc9 and below, I believe) are not going to get Iain's @rpath fixes and will build broken binaries unless the needed rpath search paths are added manually to every build, which I don't recommend.

So gccs less than gcc10 will need to be blacklisted I suppose on MacOS 10.11 and newer.

It is quite possible that some broken software out there will need to be rebuilt to get the needed rpaths embedded in them.

[kencu (Ken)]

and gcc-devel/libgcc-devel on Intel will need to be considered.

Either it can stay as it is (pure upstream on Intel) and for now, be the only one that is not using @rpath libraries, or it can change as well to Iain's fork and will use @rpath like all the others, which is more consistent, although not "pure upstream".

All fallout from the @rpath change, all predicted and predictable.

FWIW, I've been using gcc with @rpath gcc libraries for some months now, myself, in anticipation of this change coming.

[kencu (Ken)]

ping Michael, as he has been bumping gcc-devel on Intel lately

[cjones051073 (Chris Jones)]

or... just remove support for gcc10 or 11 on the newer systems. Why use them instead of gcc12 ?

[kencu (Ken)]

Having only gcc12 available on 10.11 and up would certainly allow cleanups to occur in a lot of places :).

Not sure how that would resonate though…removes a lot of current flexibility, and gcc12 is very new.

gcc10 and gcc11 have been fixed to add the needed rpaths, and so they are there for use if there is any interest in supporting more than one gcc version on MacPorts on 10.11+ at present.

(btw IMHO we should just get our gccs directly from Iain, as he has been recommending, instead of using FX’s copies of Iain’s patches. Using FX’s copies just introduces an extra source of possible error).

[cjones051073 (Chris Jones)]

See last three commits to ​https://github.com/cjones051073/macports-ports/commits/gcc-iain-update

Going to run some quick tests but then push to master quite quickly given the issues gcc10 and gcc11 currently have.

[kencu (Ken)]

fantastic work, Chris -- thanks for taking the reins on this.

[Chris Jones <jonesc@…>]

In 2cf253253e0444f10d1c2f855e2631a5c1d78a14/macports-ports (master):

compilers PG: Only support gcc 10+ on OSX10.11+
See: #65472

[cjones051073 (Chris Jones)]

I think this can be closed now…

[kencu (Ken)]

Thanks!

Iain tells me that he intends to fix several earlier gcc versions to automatically insert the needed rpath reference as well, so some of those might come back into being usable again.