Opened 3 years ago

Last modified 10 months ago

#54289 assigned update

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

Reported by: RJVB (René Bertin) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: potmj, chrstphrchvz (Christopher Chavez), kencu (Ken)
Port: libcxxabi libcxx

Description

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

Attachments (6)

lcxxabi.diff (1.9 KB) - added by RJVB (René Bertin) 3 years ago.
libcxxabi upgrade to 4.0.0
lcxxabi+runtime.diff (3.7 KB) - added by RJVB (René Bertin) 3 years ago.
port:libcxxabi +runtime variant
lcxx.diff (1.7 KB) - added by RJVB (René Bertin) 3 years ago.
lcxx+runtime.diff (3.1 KB) - added by RJVB (René Bertin) 3 years ago.
libcxx-runtime.diff (5.2 KB) - added by RJVB (René Bertin) 3 years ago.
update for libcxx 5.0.1
main.log (25.8 KB) - added by potmj 3 years ago.
Leopard port -v upgrade libcxx

Download all attachments as: .zip

Change History (20)

Changed 3 years ago by RJVB (René Bertin)

Attachment: lcxxabi.diff added

libcxxabi upgrade to 4.0.0

Changed 3 years ago by RJVB (René Bertin)

Attachment: lcxxabi+runtime.diff added

port:libcxxabi +runtime variant

Changed 3 years ago by RJVB (René Bertin)

Attachment: lcxx.diff added

Changed 3 years ago by RJVB (René Bertin)

Attachment: lcxx+runtime.diff added

comment:1 Changed 3 years ago by mf2k (Frank Schima)

Cc: jeremyhu removed
Owner: set to jeremyhu
Status: newassigned

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

Changed 3 years ago by RJVB (René Bertin)

Attachment: libcxx-runtime.diff added

update for libcxx 5.0.1

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by potmj

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?

Last edited 3 years ago by potmj (previous) (diff)

Changed 3 years ago by potmj

Attachment: main.log added

Leopard port -v upgrade libcxx

comment:6 Changed 3 years ago by potmj

Cc: potmj added

comment:7 Changed 3 years ago by 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!

comment:8 Changed 3 years ago by 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?

comment:9 Changed 3 years ago by potmj

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?

comment:10 Changed 3 years ago by RJVB (René Bertin)

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

comment:11 in reply to:  8 Changed 3 years ago by potmj

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 is built with gcc (g++4.2). 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.

Last edited 3 years ago by potmj (previous) (diff)

comment:12 Changed 18 months ago by chrstphrchvz (Christopher Chavez)

libcxxabi is obsolete: [abd34b7635/macports-ports]

comment:13 Changed 18 months ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:14 Changed 10 months ago by kencu (Ken)

Cc: kencu added
Note: See TracTickets for help on using tickets.