libomp: build fat library on x86_64 to provide i386 support

[howarth.at.macports@…]

The attached Portfile diff passes -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386" to cmake on x86_64 to build the fat library for libomp.

[howarth.at.macports@…]

Portfile diff to build fat libomp on x86_64

[howarth.at.macports@…]

Sorry about the multiple uploads of the diff. Both are now the same with the missing backslash added before the colon in the cmake option (to keep port from being confused by the colon).

[jeremyhu (Jeremy Huddleston Sequoia)]

I prefer to wait for a fix for the more general problem. See ​https://llvm.org/bugs/show_bug.cgi?id=25885

[jeremyhu (Jeremy Huddleston Sequoia)]

because this change alone won't address the problem with libclang_rt, there's not much benefit to it. Closing as wontfix, but really it will be fixed once the upstream bug is fixed.

[howarth.at.macports@…]

What are you talking about? It works perfectly.

Confirmed that the OpenMP3.1_Validation test suite compiled with clang-mp-3.8 compiler, produced with the llvm-3.8 changes proposed in ticket #50509, using '-O3 -fopenmp -m32' shows the expected results...

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:                123
S Number of failed tests:              5
S Number of successful tests:          118
S + from this were verified:           113

Normal tests:
N Number of failed tests:              2
N + from this fail compilation:        0
N + from this timed out                0
N Number of successful tests:          60
N + from this were verified:           57

Orphaned tests:
O Number of failed tests:              3
O + from this fail compilation:        0
O + from this timed out                0
O Number of successful tests:          58
O + from this were verified:           56

[howarth.at.macports@…]

Replying to jeremyhu@…:

I prefer to wait for a fix for the more general problem. See ​https://llvm.org/bugs/show_bug.cgi?id=25885

That issue seems entirely orthogonal to this issue. Please read ​http://lists.llvm.org/pipermail/openmp-dev/2015-May/000636.html which contains the origins of -DLIBOMP_OSX_ARCHITECTURES='i386;x86_64' which was specifically designed to build the libomp library as far without foisting an entire fat toolchain on the user.

[jeremyhu (Jeremy Huddleston Sequoia)]

What architectures are in your versions of:

  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.10.4.a
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.cc_kext.a
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.safestack_osx.a
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib
  /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib

Those need to be fat. The suggested changes don't address that problem. I'm glad that your restricted test cases work fine, but it won't be realistically useful until ​https://llvm.org/bugs/show_bug.cgi?id=25885 is addressed.

I am quite aware of the problem. I'm not expecting to force an entire fat toolchain on the users. The toolchain should be the architecture that they're building MacPorts for (ie, CHOST in automake language), the runtime libraries should be the architecture that the toolchain can target (ie: CTARGET in automake language).

[jeremyhu (Jeremy Huddleston Sequoia)]

Actually, it looks like those runtime libraries do now contain the appropriate slices. The issue is just that they're doing a union of architectures, which creates a problem for users running on i386.

So given that, why doesn't libomp use the same mechanism as compiler_rt for determining the target architectures? That seems like a more appropriate fix.

[howarth.at.macports@…]

$ file /opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/*
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.10.4.a:                  Mach-O universal binary with 2 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.10.4.a (for architecture i386):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.10.4.a (for architecture x86_64):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:  Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib (for architecture x86_64h):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.cc_kext.a:               Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.cc_kext.a (for architecture i386):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.cc_kext.a (for architecture x86_64):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.cc_kext.a (for architecture x86_64h):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.eprintf.a:               current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a:                   Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a (for architecture i386):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a (for architecture x86_64):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a (for architecture x86_64h):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a:           Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a (for architecture i386):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a (for architecture x86_64):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a (for architecture x86_64h):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.safestack_osx.a:         Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.safestack_osx.a (for architecture i386):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.safestack_osx.a (for architecture x86_64):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.safestack_osx.a (for architecture x86_64h):	current ar archive random library
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib:  Mach-O universal binary with 2 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib (for architecture x86_64h):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib: Mach-O universal binary with 3 architectures
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/libexec/llvm-3.8/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (for architecture x86_64h):	Mach-O 64-bit dynamically linked shared library x86_64

[howarth.at.macports@…]

Replying to jeremyhu@…:

So given that, why doesn't libomp use the same mechanism as compiler_rt for determining the target architectures? That seems like a more appropriate fix.

The libomp build machinery was inherited from the original openmp project code which was a perl based build system. The fat libomp has always been built by compiling libomp twice into separate directories and then lipo'ing to sets of binaries together. I wouldn't be holding my breath to see this redesigned anytime soon as they have far more important things to do with openmp 4.5 support.

[howarth.at.macports@…]

The builds now occur in a single directory with -arch x86_64 -arch i386 when using -DCMAKE_OSX_ARCHITECTURES='i386;x86_64' or -DLIBOMP_OSX_ARCHITECTURES='i386;x86_64'.

[howarth.at.macports@…]

Note that ticket #50509 bumps the revision to 259372 which is what my llvm-3.8/clang-3.8 builds are based on.

[howarth.at.macports@…]

I would note that the libcxx sources also have no mechanism to automatically detect and build all supported architectures on darwin so it seems a tad unreasonable to demand the openmp developers alone implement that. Looking at sources in compiler-rt/cmake regarding the requested automation, those changes will be fairly extensive and seem a rather heavy burden to foist on the openmp developer when libcxx isn't being held to the same requirement.

[eborisch (Eric A. Borisch)]

For the record, the libomp port currently uses the MacPorts muniversal portgroup rather than relying on the underlying tools to support multi-arch compilation. It's a small and fast enough config+build such that this seemed to be a reasonable approach rather than waiting for the underlying tools to support.

[howarth.at.macports@…]

update to apply against current Portfile

[howarth.at.macports@…]

I am still baffled why such a simple fix to this issue is being rejected. Upstream is not going restructure their openmp build anytime soon.

--- Portfile.orig	2016-03-18 15:03:53.000000000 -0400
+++ Portfile	2016-03-18 15:04:33.000000000 -0400
@@ -53,6 +53,10 @@
 configure.args-append   -DCMAKE_INSTALL_RPATH=${prefix}/lib/libomp \
                         -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib/libomp \
 
+if {${build_arch} eq "x86_64"} {
+    configure.args-append   -DLIBOMP_OSX_ARCHITECTURES="x86_64\;i386"
+}
+
 variant top_level description \
     "Install (links to) omp.h and libs into ${prefix}/(include|lib)" {}
 

[eborisch (Eric A. Borisch)]

Do you not already get what you want (a fat libomp.dylib) using the +universal variant? Please let me know if I am missing something.

$ port echo active and libomp
libomp                         @0.0_261249+universal
$ file /opt/local/lib/libomp/libomp.dylib
/opt/local/lib/libomp/libomp.dylib: Mach-O universal binary with 2 architectures
/opt/local/lib/libomp/libomp.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/opt/local/lib/libomp/libomp.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64

[howarth.at.macports@…]

The cmake build machinery in openmp is currently set up to only build single architecture unless explicitly told which additional architectures to build. Furthermore, it does this by building the architectures separately in individual subdirectories and then uses lipo to combine them into a single binary. This issue is obvious by simple inspection of library installed by libomp-0.0_261249.darwin_15.x86_64.tbz2...

$ file /opt/local/lib/libomp/libomp.dylib
/opt/local/lib/libomp/libomp.dylib: Mach-O 64-bit dynamically linked shared library x86_64

and the requirement to explicitly set is clearly noted in openmp-3.8.0.src/runtime/Build_With_CMake.txt

==================
Mac* Fat Libraries
==================
On OS X* machines, it is possible to build universal (or fat) libraries which
include both i386 and x86_64 architecture objects in a
single archive.
 $ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_OSX_ARCHITECTURES='i386;x86_64' ..
 $ make
There is also an option -DLIBOMP_OSX_ARCHITECTURES which can be set in case
this is an LLVM source tree build which will only set the libomp library
to a universal fat library and prevent having the entire llvm/clang build
produce universal binaries.

[howarth.at.macports@…]

Note that we want to use the -DLIBOMP_OSX_ARCHITECTURES option instead of -DCMAKE_OSX_ARCHITECTURES. Use of -DCMAKE_OSX_ARCHITECTURES bloats the llvm build by creating the entire tool chain as fat binaries. The -DLIBOMP_OSX_ARCHITECTURES option was added to explicitly avoid that problem.

[howarth.at.macports@…]

The exact usage of the -DLIBOMP_OSX_ARCHITECTURES option occurs in openmp-3.8.0.src/runtime/CMakeLists.txt at...

# - Support for universal fat binary builds on Mac
# - Having this extra variable allows people to build this library as a universal library
#   without forcing a universal build of the llvm/clang compiler.
set(LIBOMP_OSX_ARCHITECTURES "${CMAKE_OSX_ARCHITECTURES}" CACHE STRING
  "For Mac builds, semicolon separated list of architectures to build for universal fat binary.")
set(CMAKE_OSX_ARCHITECTURES ${LIBOMP_OSX_ARCHITECTURES})

[howarth.at.macports@…]

My mistake. I was assuming that the universal variant was the default for libomp. Shouldn't the Portfile be changed then to make it the default variant since the default compiler on x86_64 supports both i386 and x86_64 code generation? The current situation seems unnecessarily confusing to the end-user.

[eborisch (Eric A. Borisch)]

I'm happy to make universal the default here. When built with the universal variant, are you getting what you want?

[howarth.at.macports@…]

Yes. The universal variant produces the expected results for the OpenMP3.1_Validation test suite when using the clang-mp-3.8 compiler and the "-fopenmp -O3 -m32" flags. So the i386 support is working properly in the +universal variant of libomp.

[eborisch (Eric A. Borisch)]

OK. I will update that (+universal) to be the default here shortly. Wasn't trying to ignore you; just felt that things were (and apparently are) working with +universal.

[eborisch (Eric A. Borisch)]

Added +universal to default_variants in r147078.