libcxx{,-abi} : upgrade + "runtime" variant

[RJVB (René Bertin)]

I'm submitting 2 patches for the libcxxabi and libcxx ports:

• upgrade to 4.0.0 (with a small mod to let ${configure.optflags} be respected)
• introduction of a +runtime variant

The principle of the variant was discussed with Jeremy a while back already, and I've been testing it since. It provides an alternative install option for users who do not need to do a libc++ conversion (new enough OS), who wouldn't want to do that anyway, but who'd still be interested in using an up-to-date C++ runtime with software that could benefit.

In its current implementation this installs runtime versions of the c++abi and c++ libraries into ${prefix}/lib (libc++abi.1.dylib and libc++.1.dylib) and provides a simple launch script that sets (and instructions how to set) DYLD_INSERT_LIBRARIES. This will of course not work with sandboxed applications, but should work with applications provided through MacPorts (at least that's the case on OS X 10.9). The linker interface symlink libc++.dylib isn't installed (and libc++abi.dylib installed under a different name) so that they are not picked up by the link editor by accident.

I suppose one could take this approach a step further, doing a full install into ${prefix}, in such a way that opportunistic dependencies on the port can be avoided.

There is one clear positive effect of using the newer C++ runtime & ABI layer on 10.9 : the frequent log dynamic_cast errors I saw about type_info visibility in Qt4 applications stopped appearing in the system.log . This OS version might also benefit from having a full install in ${prefix} against which applications can be linked.

I'll be attaching the portfile patches only here, for the patchfiles please refer to

​https://github.com/RJVB/macstrop/tree/master/lang/libcxxabi/files ​https://github.com/RJVB/macstrop/tree/master/lang/libcxx/files

[RJVB (René Bertin)]

libcxxabi upgrade to 4.0.0

[RJVB (René Bertin)]

port:libcxxabi +runtime variant

[kencu (Ken)]

Funny, I had thought _cxa_atexit() was actually important to have <​https://stackoverflow.com/questions/42912038/what-is-the-difference-between-cxa-atexit-and-atexit>, <​https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-motivation>. But what do I know? See what Jeremy says, I guess.

[RJVB (René Bertin)]

It may be but when I include the file I'm getting a link error. If you look at the CMake files you'll see that the file isn't meant to be used on Mac at all.

[RJVB (René Bertin)]

update for libcxx 5.0.1

[RJVB (René Bertin)]

Updated for port:libcxx 5.0.1, adds a wrapper script to run only specific applications with the newer libc++.

Also, a tweak that makes the build respect configure.optflags. If you're going to use a custom-built libc++ it could just as well be one with additional optimisation or rather optimal debugging aptitudes.

[potmj (Michael Pot)]

Could this affect new users starting out with ​https://trac.macports.org/wiki/LibcxxOnOlderSystems, Bootstrapping 2: part 2. [+universal builds, intel] on Leopard?

I had been slowly working through this page, getting to about Bootstrapping 3: part 6, but in the mean time I have run port selfupdate. Now things are outdated and it seems I need to upgrade libcxx. It is not going well, as clang-3.7 is not properly building the ppc part because of a problem with libclang_rt.osx.a.... (I could only get clang-3.4 to build a -universal clang-3.7)

I have wound back the macports.config changes in Bootstrapping 3: etc, deactivated clang-3.7, etc, but still failing to upgrade libcxx. Do we need to now add some 'configure.compiler=' option on the command line or something for

port -v upgrade libcxx

to work on Leopard?

[potmj (Michael Pot)]

Leopard port -v upgrade libcxx

[kencu (Ken)]

on the 10.5 intel machine, your best bet is to set the universal_archs in macports.conf to i386 + x86_64, like this:

universal_archs i386 x86_64

You should find, as I did, that works quite easily.

$ port -v installed libcxx
The following ports are currently installed:
  libcxx @5.0.1_0+universal (active) platform='darwin 9' archs='i386 x86_64' date='2017-12-29T13:56:55-0800'

ppc is another whole kettle of fish. Indeed, you cannot presently build libclang_rt.osx.a with a PPC slice very easily at all. I have been able to build it manually on a PPC machine using gcc6, and then move the PPC slice over and lipo it together with the intel slices.

If clang / libcxx on PPC is your goal, I could use some help and inspiration!

[RJVB (René Bertin)]

Could you please move this to a dedicated ticket?

Also, if the target intel machine is 32bit as I suspect, I'd advise strongly to ignore the instructions to do universal builds. You won't ever be able to use the 64bit slices on that machine, so why waste time building them (knowing that it must already be very slow to current standards).

I'd also try with clang 3.5, new enough to build libcxx 5 but not so new it might give build problems. Alternatively, try GCC like Ken suggested.

Interesting question: is libc++ built with GCC and itself depending on libstdc++ (instead of libc++abi, as on Linux) a viable candidate for the libc++ conversion?

[potmj (Michael Pot)]

The question is has the bump to 5.0.1_1 broken something? 5.0.1_0 built +universal on Leopard intel.

port -v installed libcxx
The following ports are currently installed:
  libcxx @3.9.1_0-universal platform='darwin 9' archs='i386' date='2017-09-09T16:36:04+1200'
  libcxx @3.9.1_1-universal platform='darwin 9' archs='i386' date='2017-12-28T01:13:04+1300'
  libcxx @5.0.1_0-universal platform='darwin 9' archs='i386' date='2017-12-30T09:05:22+1300'
  libcxx @5.0.1_0+universal (active) platform='darwin 9' archs='i386 ppc x86_64' date='2018-01-09T09:07:46+1300'

Shall I open a ticket for that?

[RJVB (René Bertin)]

Yes, please do not pollute this ticket with unrelated things.

[potmj (Michael Pot)]

Replying to RJVB:

Interesting question: is libc++ built with GCC and itself depending on libstdc++ (instead of libc++abi, as on Linux) a viable candidate for the libc++ conversion?

It looks like it. I guess the whole idea of bootstrapping is to provide a path to clang from gcc, as indicated by: Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option. Somehow libstdc++ is not included (needed) - clever stuff I guess.

otool -L /usr/lib/libc++.1.dylib 
/usr/lib/libc++.1.dylib:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
otool -L /usr/lib/libc++abi.dylib 
/usr/lib/libc++abi.dylib:
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)

With the advantage that the old Xcode gcc can generate ppc i386 x86_64 universals that work eveywhere.

[chrstphrchvz (Christopher Chavez)]

libcxxabi is obsolete: [abd34b7635/macports-ports]

[mascguy (Christopher Nielsen)]

Rene, is this ticket still relevant, now that libcxxabi is obsolete...?

[RJVB (René Bertin)]

The principle of a runtime variant is still as relevant as it ever was, of course.