clang >= 3.4: Unable to build/bootstrap on Intel Tiger

[dgelessus (dgelessus)]

It is currently not possible to build clang-3.4 or newer on Intel Tiger. As a result, any ports that require C++11 cannot be built on Tiger, because MacPorts selects a recent clang (currently 9.0) when looking for a C++11-capable compiler.

This issue is somewhat complex because a lot of bootstrapping is involved, and multiple ports in the bootstrap process don't work properly on Tiger. The (simplified) bootstrap dependency chain looks like this:

• Xcode 2.5 gcc
• apple-gcc42
• clang-3.4
• libcxx
• clang-3.7
• icu
• libxml2
• cmake
• libomp
• newer clang (e. g. 9.0)

So far I've run into the following individual issues in the chain:

• (no longer applies) clang-3.4 requires libxml2 to build, which requires icu. icu requries a C++11 compiler, and MacPorts selects clang-3.4 here, which leads to a circular dependency.
  • The clang-3.4 Portfile already has a special case to handle this issue, but it doesn't get triggered on Tiger, because the cxx_stdlib is set to libstdcxx and not libcxx.
  • I've submitted a fix for this as ​PR 5771.
  • This has been fixed by @kencu in ​commit 57b3421, by disabling the parts of clang-3.4 and clang-3.7 that require libxml2.
• llvm/clang-3.7 always wants libcxx as its C++ stdlib, but the libcxx port doesn't support Tiger.
  • I've attempted to make libcxx build on Tiger in ​a branch of my fork. This isn't tested very well yet. (I've previously submitted this as ​PR 5783, but these changes likely won't be merged into the main ports tree, to avoid breaking newer systems.)
  • Perhaps an alternative fix would be to make clang use libstdcxx instead of libcxx on Tiger. I haven't looked into this further yet, but @kencu has ​a customized llvm/clang-3.8 port that uses libstdcxx, so it seems to be possible.
• llvm-3.7 references a couple of macros that don't exist on Tiger.
  • This only requires some very minor patches, which can be found in ​my fork's llvm_3_7_tiger branch.
• The clang-3.7 build fails to build the compiler-rt libraries for the clang_darwin target (the clang_macho_embedded ones get built properly). make thinks that there is nothing to be done for the clang_darwin target, so no libraries are built, which causes later parts of the build (that expect the libraries to exist) to fail.
  • This appears to be a similar issue to #54836 and #59157.
  • This is also fixed in ​my fork's llvm_3_7_tiger branch.
• The current version of icu requires C++11, so MacPorts tries to compile it with MacPorts Clang 3.4. However, icu needs to be built against libstdc++ (the default C++ stdlib on Tiger), which is not possible with Clang older than 3.8.
  • As a workaround, icu can be compiled using GCC 7. (GCC 6 gives some strange errors when building icu.) The disadvantage of this solution is that it requires installing GCC, which takes a while and isn't required anywhere else in the bootstrap chain.
• cmake has problems with libgcc 7.5, see #59832.
  • If libgcc7 is manually downgraded to a 7.4 version (e. g. libgcc7 @7.4.0_3), cmake builds and runs without issues.
• libomp defaults to +universal. This is meant to ensure that it gets built for both i386 and x86_64. However, +universal builds on Tiger default to building for i386 and ppc, not i386 and x86_64. This causes the installation to fail, because libomp only supports i386 and x86_64, and not ppc.
  • This can be easily worked around by installing libomp manually with -universal.
  • A better fix would probably be to change libomp's Portfile so that it doesn't default to +universal if non-Intel archs appear in universal_archs.
• The cmake portgroups (1.0 and 1.1) unconditionally set CMAKE_BUILD_WITH_INSTALL_RPATH to ON. This causes all CMake-based builds to fail on Tiger, because @rpath is only supported since Leopard.
  • This could probably be fixed in the cmake portgroups, by setting CMAKE_BUILD_WITH_INSTALL_RPATH only on Leopard and newer.

I've already discussed some of these issues separately on IRC and GitHub (thanks to @jmroot and @kencu for the help so far!). This ticket is meant to be an overview of how the issues are related, as the issues further down the list usually can't be observed without first fixing/working around the previous issues.

Also I'm not sure what the best solutions are for some of the issues, or if it even makes sense to use clang (rather than gcc) as the C++11 compiler on Tiger. Any opinions and suggestions are welcome.

[kencu (Ken)]

So I have clang-3.8 running on Tiger with our macports-libstdc++ modification enabled. That is a pretty good start. Will help you over next few days to get up to there.

[kencu (Ken)]

may I first say --- are you sure you want to do this? If it's for fun and sport, fine. Otherwise, forget it. It's a massive sinkhole of frustrations, many things won't work, and the SDK is years inferior to Leopard (which is way better but still very frustrating). Go with 10.6.8 or 10.7.5 and you'll be miles and miles and miles more functional.

Tiger PPC is fun for MacOS9. Tiger intel is good for not much, other than crosscompiling for TigerPPC, which it really can't do until/unless I fix up a current gcc crosscompiler.

rpaths don't (currently) work on Tiger, so lots of build systems fail. etc.

If I haven't lost you yet, keep reading...

[kencu (Ken)]

you can expect almost nothing in the macports bootstrapping code (recently hatched) to work. It doesn't even work on Leopard Intel yet, which is a good place to start (meet Riccardo..). So have no expectations about that.

Almost nobody on MacPorts uses Tiger Intel (me, and .. uh.. ).

None of clang or llvm is ever tested on <10.6 except for a few of us diehards. There are many holes to fill.

With all that in mind, and your expectations hopefully suitably moderated, see <​https://github.com/kencu/TigerPorts/tree/master/lang/llvm-3.8> and associated software there...

[kencu (Ken)]

you can't backport macports-libstdc++ into clang 3.4, I believe, as the guts that make it work didn't show up until clang-3.9, and were backported into 3.8. but 3.4 is too far back to go, and --- why? use 3.8 instead.

And then perhaps that can be used to leap to clang-5.0. clang-3.4 can't build a working compiler newer than clang-3.7 (anything later might build but crashes in use).

[kencu (Ken)]

your go-to compiler on Tiger, at present, is gcc7, although there are many ports it won't build due to headers, build system assumptions, rpath missing, and general non-posix compliance in Tiger...

[dgelessus (dgelessus)]

are you sure you want to do this? If it's for fun and sport, fine. Otherwise, forget it.

My fun and sport is unusual ;) So far I haven't run into anything that seems unreasonably complicated to fix, so I want to see how far I can get. I'm aware that Intel Tiger doesn't have much practical use (and I have this machine dual-booted to 10.7, which I use for most things), but I'm happy to submit patches for any part of this that I can work out. (As long as MacPorts core accepts it - if this would be better off in a separate repo to not clutter up the core, let me know.)

you can't backport macports-libstdc++ into clang 3.4, I believe, as the guts that make it work didn't show up until clang-3.9, and were backported into 3.8.

Interesting. I didn't have much trouble adjusting the +libstdcxx patch file from 5.0 to work with 3.4 and 3.7, though I haven't tested if it actually works as expected. All I know is that the flag is accepted and clang doesn't crash as a result. Right now I only use -stdlib=macports-libstdc++ in clang-3.4 to work around some quirk with how clang-3.7's configure script is called (when checking that the C++ compiler is working, it includes the flag, even though the rest of the llvm/clang-3.7 build uses -stdlib=libc++). I need to look into that again in more detail, it's probably better to fix the configure script than to patch clang-3.4 just for that.

but 3.4 is too far back to go, and --- why? use 3.8 instead.

Currently I'm following the bootstrap chain that MacPorts suggested by default. clang-3.4 and libcxx are apparently working (nothing crashed yet at least) and the clang-3.7 build is in progress right now. That would allow building newer clangs, assuming everything worked up to that point. Of course, the newer clangs will most likely require more work to get running on Tiger...

I'm also fairly certain that this bootstrap sequence worked fine in the past (at some point during MacPorts 2.5.4, which I know isn't very specific). That installation broke at some point (couldn't upgrade most ports anymore, because almost everything triggered the dependency cycle in clang-3.4), so I uninstalled almost everything and tried to get the clang versions installed again.

I haven't tried anything using gcc yet - it's quite possible that that would be a better route than the old clang versions.

[kencu (Ken)]

the c++11 libstdc++ support in llvm landed here <​https://reviews.llvm.org/D18035> and here <​https://reviews.llvm.org/D17567> and that made it into clang-3.9. Debian backported that to clang-3.8 with moderate effort, and that's what formed part of my working clang-3.8-on-Tiger port above.

The MacPorts-specific part adds acceptance for the macports-libstdc++ flag, and changes some header lookup dirs, but does not actually function without the llvm support, of course, even if it accepts the flag.

The fact that macports base sends the macports-libstdc++ flag to clang 3.4 and clang 3.7 in the first place is a reported base bug. Those two compilers support c++11 only building against libc++.

MacPorts has dropped clang-3.6 to 4.0, and threatens to drop 5.0 soon, so that will influence stepping stones and focus effort.

[dgelessus (dgelessus)]

The MacPorts-specific part adds acceptance for the macports-libstdc++ flag, and changes some header lookup dirs, but does not actually function without the llvm support, of course, even if it accepts the flag.

Ah, I already expected something like that. At least the patch works well enough on the older versions that the accidental clang-3.4 -stdlib=macports-libstdc++ call runs without errors.

For reference, #59584 is the MacPorts base ticket for this issue.

I let my clang-3.7 build run overnight (llvm-3.7 already built successfully). Most of the build ran without problems, but now I'm getting this error in the compiler-rt build:

llvm[3]: Copying runtime library darwin/eprintf to build dir
cp /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.eprintf.a
llvm[3]: Copying runtime library darwin/10.4 to build dir
cp /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/10.4/libcompiler_rt.a /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.10.4.a
cp: /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a: No such file or directory
gmake[3]: *** [Makefile:241: /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.eprintf.a] Error 1
gmake[3]: *** Waiting for unfinished jobs....
cp: /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/10.4/libcompiler_rt.a: No such file or directory
gmake[3]: *** [Makefile:241: /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.10.4.a] Error 1
rm /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/.dir /opt/local/var/macports/build/_Users_Shared_macports-ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/macho_embedded/.dir

This issue (or a very similar one) has been reported before as #54836, but it doesn't look like it was ever fixed. #59157 is a similar issue, but with a different cause (command-line tools vs. full Xcode installation, which is not an issue on Tiger). That ticket may be useful as it has a detailed analysis of what causes the issue, which might help with finding the root cause on Tiger.

[kencu (Ken)]

we can't have clang-3.4 and clang-3.7 appear to accept -stdlib=macports-libstdc++ but then have it non-functional, so patches to allow that can't be the right way to go.

llvm 3.5+ need a working c++11 compiler to build functional software.

#54836 is something different (now closed), but does illustrate that during the build of clang's darwin RT many things can go wrong that result in no library being produced.

#59157 again something different, but illustrates the same point. In that case, the SDK is not being found (which is also an issue building clang-3.8 on Tiger, fixed with a ​patch in my build).

[kencu (Ken)]

Do you have any enthusiasm for trying a build of the working clang-3.8 on Tiger? Most of the issues you are bumping your head against have already been fixed there, and I chose that version of clang as it's old enough to build on Tiger but new enough to be useful, supporting -stdlib=macports-libstdc++ etc.

If you get around to giving that a try, let me know how it does (or doesn't) build for you. I have it installed and I"m using it with reasonable success.

In the meantime, I'll look at libc++ again and see if there is a way to make a functional version for Tiger that at least doesn't grossly fail the test suite, and that doesn't break 10.5 and 10.6 (and newer) where it is really needed.

[dgelessus (dgelessus)]

Thanks for the link to the patch, with that I was able to build clang-3.7. The compiler appears to be working (haven't tested much more than a C "Hello World" yet though), which I suppose confirms that my built libcxx is working?

I'm now trying to build cmake, as it is required to build any newer clang version (including the clang-3.8 from your TigerPorts repo), and I'm having trouble finding a compiler that can build a working cmake. When building with GCC 6 or 7, the "initial CMake" binary crashes with a bus error. (These GCC versions are whitelisted by the cxx11 1.1 portgroup.) According to the comment at the top of the llvm-3.7 Portfile, Clang 3.7 should be able to build a working CMake, but when built with that compiler, CMake still crashes like with GCC. I also tried Clang 3.4 just in case, but with that the build errors out somewhere in the libstdc++ headers. (With a normal Tiger environment, Clang 3.4 and 3.7 wouldn't even be an option here anyway. The cmake port builds against MacPorts libstdcxx, which my Clang 3.4 and 3.7 only support because of my possibly broken patch to accept -stdlib=macports-libstdcxx.)

[dgelessus (dgelessus)]

MacPorts cmake was recently updated to 3.16.1, so I tried building the new version on my system.

First I got the compile errors that have already been reported in #59772, which I am able to fix using the ​patch you (kencu) posted in that issue. However even with the patch I get the same bus error that I already got with cmake 3.15.5.

This time I figured out how to get a proper crash report from the bootstrap cmake binary (see attachment). The stack trace points into an atomic int operation in libstdcxx:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   libstdc++.6.dylib 	0x90b40517 _gnu_cxx::__exchange_and_add(int volatile*, int) + 9
1   libstdc++.6.dylib 	0x90b4c9a2 std::locale::_Impl::_M_remove_reference() + 26
2   libstdc++.6.dylib 	0x90b06bfd std::locale::~locale [in-charge]() + 19
3   cmake             	0x00080570 cmGeneratedFileStream::~cmGeneratedFileStream [not-in-charge]() + 74
4   cmake             	0x000804c6 cmGeneratedFileStream::~cmGeneratedFileStream [in-charge]() + 34
5   cmake             	0x001a6f6b cmake::~cmake [not-in-charge]() + 431
6   cmake             	0x001b4a69 main + 3383
7   cmake             	0x0000b85a _start + 216
8   cmake             	0x0000b781 start + 41

I searched the issue tracker but couldn't find any previous reports similar to this.

Also, I noticed that the build now selects MacPorts Clang 3.4 by default rather than GCC as before. No idea if that means anything, but it is interesting because I tested building cmake 3.15.5 with that compiler before, and it failed to parse some standard headers included by cmake. With cmake 3.16.1 that doesn't seem to be an issue anymore.

[dgelessus (dgelessus)]

Bootstrap cmake 3.16.1 crash report

[kencu (Ken)]

I have removed the need for libxml2 (and therefore icu and possibly others) during the bootstrap of clang-3.4.

Hopefully this should get us to clang-3.4 more easily.

If possible without wreckage, I'll add your libcxx tweaks for 10.4.

[dgelessus (dgelessus)]

Regarding the edit I just made:

The configure script of icu tries to call clang-3.4 with the option -stdlib=macports-libstdc++, even though icu will be built against libc++ (via the clang_dependency 1.0 portgroup).

I think I got that wrong. According to the code in clang_dependency-1.0.tcl, the portgroup doesn't change anything about the C++ stdlib, it just blacklists some clang versions. So the C++ stdlib used by icu would be libstdc++, which clang-3.7 can't compile against. This might explain my previous problems with building cmake...

[kencu (Ken)]

I looked over your github branches, and initially I have had some kind of trouble building libcxx -- I'll try again.

I did get a full install of libc++/libc++abi version 7.1.0 bootstrapping from bare metal using gcc7 to build it, on 10.6. That might be useful. I'll see how that goes.

For now, the path Jeremy has plowed using gcc-4.0 -> apple-gcc-4.2 -> clang-3.4 -> libc++ -> clang-3.7 -> clang-5.0 -> libc++ with tls remains our rather long, circuitous, but workable path on 10.5+. Hopefully we can make that go for 10.4 as well.

[kencu (Ken)]

just an FYI, it turns out port:libxml2 and port:icu are not actually needed for any versions of llvm or clang -- you can just delete the dependency out of the portfile.

The llvm build will find the system one and that works fine.

You can force that off for cmake builds for llvm/clang > 3.7, if you so desire, quite easily <​https://github.com/macports/macports-ports/blob/97c1088c4d72082616135caa092be228e52a2944/devel/libtapi/Portfile#L48> but it's also harmless to let cmake find the system libxml2 and use it (it just goes against MacPorts "dep everything" approach to building software is all, and that is the only reason it was ever in the Portfile in the first place).

I have formally carved libxml2 (and icu) out of clang/llvm 3.4 and 3.7 for simplicity.

[dgelessus (dgelessus)]

initially I have had some kind of trouble building libcxx -- I'll try again.

Let me know if you run into anything. My test environment isn't completely clean (I uninstall and rebuild ports selectively as needed), so it's possible that some steps work on my machine but not with a fresh MacPorts install.

just an FYI, it turns out port:libxml2 and port:icu are not actually needed for any versions of llvm or clang

At the moment llvm/clang isn't the issue. I have already rebuilt 3.4 and 3.7 with your changes that removed the libxml2 dependency, and I can't build any newer Clangs yet, because I don't have CMake working yet. CMake has some dependencies that require icu/libxml2, and in those places we probably can't just remove the libxml2 dependencies. (The dependency chains are cmake -> curl -> libpsl -> glib2 -> libxml2, and cmake -> libarchive -> libxml2.)

I was now able to build icu by forcing configure.compiler=macports-gcc-7 (macports-gcc-6 fails with a weird error that I didn't bother to debug). All other dependencies of cmake built normally. I'm now trying to see if I can build cmake itself using macports-gcc-7 as well.

[kencu (Ken)]

If you get stuck use my cmake39 port. No c++11 needed

[dgelessus (dgelessus)]

Update: cmake built with macports-gcc-7 still crashes with exactly the same bus error as before. This at least confirms that the cmake crash has nothing to do with my hacky -stdlib=macports-libstdc++ patches for clang-3.4/3.7 (I've removed these patches again from my current clang builds).

I think the cmake crash has already been reported in #59832 - apparently it's related to libgcc7 7.5.0, and the suggested fix is to go back to 7.4, which I'm trying now. If that doesn't work either, I'll try your cmake39 port.

[dgelessus (dgelessus)]

I was able to successfully build the current cmake by downgrading to libgcc7 @7.4.0_3:

` $ cmake --version cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake). -> exit 0 `

If I switch back to libgcc7 @7.5.0_0 and run cmake --version again, I get this error repeatedly:

` cmake(21855) malloc: * Deallocation of a pointer not malloced: 0x10ca1ac; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug `

I also tried building your cmake39 port - that didn't work because it tries to download an archive named cmake39-3.9.4.tar.gz, which can't be found at any of the sources (the archive should probably be named cmake-3.9.4.tar.gz). Besides, if I'm reading the Portfile correctly, even cmake39 requires C++11, so it wouldn't make much of a difference in this case.

[dgelessus (dgelessus)]

Repost with correct formatting:

I was able to successfully build the current cmake by downgrading to libgcc7 @7.4.0_3:

$ cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).
-> exit 0

If I switch back to libgcc7 @7.5.0_0 and run cmake --version again, I get this error repeatedly:

cmake(21855) malloc: ***  Deallocation of a pointer not malloced: 0x10ca1ac; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

I also tried building your cmake39 port - that didn't work because it tries to download an archive named cmake39-3.9.4.tar.gz, which can't be found at any of the sources (the archive should probably be named cmake-3.9.4.tar.gz). Besides, if I'm reading the Portfile correctly, even cmake39 requires C++11, so it wouldn't make much of a difference in this case.

[kencu (Ken)]

so you are seeing that libgcc error with libgcc7 7.5.0 on Intel Tiger? up to now, the only affected system appeared to be 10.5 PPC; even 10.4 PPC was OK with 7.5.0, we thought.

It is a deep-in-the-guts abi conflict between the old system libstdc++ and the new libgcc7 libstdc++. Iain, the gcc Darwin lead, knows what the issue is, but he's finding fixing it is difficult. We may have to bump the epoch and roll back to 7.4.x once we know exactly which systems need it.

A global MacPorts rollback was vetoed a few months ago when I first noticed this.

I'll take a relook at the cmake39 port; haven't built it in a few months, so maybe something changed.

[kencu (Ken)]

btw, to have any real hope of moving forward with Tiger we'd need to "solve" thr @rpath issue. I have patched a local copy of ld64-97 to just ignore the rpath commands and not throw errors; that actually works, better than you might think. I think a wrapper script that converts the rpath commands into hard coded paths is the only real hope, and that does exist already for some other unix systems that don't support rpath.

+universal is presently a total no-go for this, and you have to strip it out of any ports that hardcode it on.

forcing compilers is a given; very few (almost no) portfile authors are worried about gcc and anything < 10.6 any longer, so the litany of fixes needed would be quite long.

Portfiles, and MacPorts in general, can only support a certain degree of spaghetti code before the system becomes unsustainable. Any changes made to MacPorts to support systems < 10.6 has to be pretty invisible to be tolerable.

[kencu (Ken)]

I have some progress to report on this issue. At present, a number of versions of llvm and clang build and work quite well on Tiger, and libc++ as well.

$ port -v installed | grep clang
  clang-3.4 @3.4.2_13 (active) platform='darwin 8' archs='i386' date='2020-03-10T15:13:46-0700'
  clang-3.7 @3.7.1_6 (active) platform='darwin 8' archs='i386' date='2020-03-20T22:12:13-0700'
  clang-3.8 @3.8.1_9+libstdcxx (active) platform='darwin 8' archs='i386' date='2020-03-14T23:15:45-0700'
  clang-5.0 @5.0.2_4+emulated_tls+libstdcxx (active) platform='darwin 8' archs='i386' date='2020-03-22T20:49:17-0700'
  clang-7.0 @7.1.0_0+emulated_tls+libstdcxx (active) platform='darwin 8' archs='i386' date='2020-03-24T15:21:13-0700'
  clang_select @2.2_0 (active) platform='darwin 8' archs='noarch' date='2020-03-10T08:07:41-0700'

$ port -v installed | grep llvm 
  llvm-3.4 @3.4.2_12 (active) platform='darwin 8' archs='i386' date='2020-03-10T13:32:13-0700'
  llvm-3.7 @3.7.1_4 (active) platform='darwin 8' archs='i386' date='2020-03-16T22:51:55-0700'
  llvm-3.8 @3.8.1_3 (active) platform='darwin 8' archs='i386' date='2020-03-14T19:15:06-0700'
  llvm-5.0 @5.0.2_1 (active) platform='darwin 8' archs='i386' date='2020-03-22T11:09:10-0700'
  llvm-7.0 @7.1.0_0+emulated_tls (active) platform='darwin 8' archs='i386' date='2020-03-24T11:26:32-0700'
  llvm_select @2_0 (active) platform='darwin 8' archs='noarch' date='2020-03-10T08:08:41-0700'

$ port -v installed | grep libcxx
 libcxx @5.0.1_4 platform='darwin 8' archs='i386' date='2020-03-16T18:37:39-0700'
  libcxx @5.0.1_4+emulated_tls (active) platform='darwin 8' archs='i386' date='2020-03-21T22:35:42-0700'

ld64-97 is working, of course (the default), and ld64-127 builds as well, but there is an issue with the crt1.o file on 10.4 compared to 10.5 and that would need to be sorted out. The cctools installation is current.

So that basically gives us something like XCode 10 on Tiger, which is pretty impressive, except for the linker, and of course, the ever-present problem with @rpath.

I don't know if you could get a newer dyld on Tiger -- at a certain point, it becomes Leopard after all :>. -- but who knows, maybe.

[kencu (Ken)]

I will see about bringing these enhancements into the general MacPorts repo over the next while, if it can be done without too much confusion. For the current moment, you can get these pieces here <​http://github.com/kencu/TigerPorts>.

[kencu (Ken)]

cmake39 is now in macports as cmake-bootstrap, so that should simplify this process that much.

[kencu (Ken)]

Patch for base portconfigure.tcl to have base not select an inappropriate clang compiler for c++11 when systems are not configured for libc++

[kencu (Ken)]

In 3ea1fb4eeb5b91940361d70634e003ec2fc572c5/macports-base (master):

portconfigure.tcl: use clang5+ for cxx11+ if not libc++

only macports-clang-5+ clang compilers will accept
macports-libstdc++

closes: #59717