libomp @17.0.3: needs compiler with atomic support

[RobK88]

I am unable to upgrade libomp to version @17.0.3 on Lion. See attached main.log.

bash-3.2$ sudo port clean libomp
--->  Cleaning libomp
bash-3.2$ 
bash-3.2$ sudo port installed libomp
The following ports are currently installed:
  libomp @16.0.6_0+universal (active)
bash-3.2$ 
bash-3.2$ sudo port upgrade libomp
--->  Computing dependencies for libomp
--->  Fetching archive for libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://packages.macports.org/libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://mirror.fcix.net/macports/packages/libomp
--->  Fetching distfiles for libomp
--->  Verifying checksums for libomp
--->  Extracting libomp
--->  Applying patches to libomp
--->  Configuring libomp
--->  Building libomp                                    
Error: Failed to build libomp: command execution failed  
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libomp/libomp/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
bash-3.2$

Workaround -- install or upgrade libomp using clang-7.0 which includes atomic support (thanks to kencu).

bash-3.2$ sudo port clean libomp
--->  Cleaning libomp
bash-3.2$ 
bash-3.2$ sudo port installed libomp
The following ports are currently installed:
  libomp @16.0.6_0+universal (active)
bash-3.2$ 
bash-3.2$ sudo port upgrade libomp configure.compiler=macports-clang-7.0
--->  Computing dependencies for libomp
--->  Fetching archive for libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://packages.macports.org/libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/libomp
--->  Attempting to fetch libomp-17.0.3_0+universal.darwin_11.i386-x86_64.tbz2 from http://mirror.fcix.net/macports/packages/libomp
--->  Fetching distfiles for libomp
--->  Verifying checksums for libomp
--->  Extracting libomp
--->  Applying patches to libomp
--->  Configuring libomp
--->  Building libomp                                    
--->  Staging libomp into destroot                       
--->  Installing libomp @17.0.3_0+universal
--->  Cleaning libomp
--->  Deactivating libomp @16.0.6_0+universal
--->  Cleaning libomp
--->  Activating libomp @17.0.3_0+universal
--->  Cleaning libomp
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  libomp has the following notes:
    To use this OpenMP library:
     * For clang-3.8+, or clang-3.7 with +openmp variant:
        add "-fopenmp" during compilation / linking.
     * For clang-3.7 without +openmp variant, use:
        "-I/opt/local/include/libomp -L/opt/local/lib/libomp -fopenmp"
bash-3.2$

[RobK88]

P.S. Same problem on Mtn Lion. The workaround is the same. Build using a compiler with atomic support such as clang-7.0.

But on Lion, for some reason, MacPorts also installed clang-3.7 for the first time. I do not know whether this is related to the bug or just a coincidence.

[eborisch (Eric A. Borisch)]

In general that won't work, since it will create a dependency loop. Looks like I'll need to pin to the old version for lion/mtn. lion.

[tehcog (tehcog)]

Replying to RobK88:

P.S. Same problem on Mtn Lion. The workaround is the same. Build using a compiler with atomic support such as clang-7.0.

But on Lion, for some reason, MacPorts also installed clang-3.7 for the first time. I do not know whether this is related to the bug or just a coincidence.

Work around seems to work on Mavericks...

[rmottola (Riccardo)]

Happens on 10.11 El Capitan too.

I tried using gcc12 I have installed, but fail:

--->  Computing dependencies for libomp...
Error: Cannot install libgcc13 for the archs 'i386 x86_64' because
Error: its dependency libmpc cannot build for the required archs.

I suppose this is not a libomp issue, but a libgcc13 issue now?

clang 6.0 worked. Is that already a dependency issue? system clang is 8.0 here... so somehow strange.

[kencu (Ken)]

The most appropriate compiler to use for this on older systems would be clang-11-bootstrap, I would think.

No circular deps with that.

If clang-11-bootstrap doesn't have atomics enabled, I can toggle that on.

[cjones051073 (Chris Jones)]

Replying to rmottola:

Happens on 10.11 El Capitan too.

I tried using gcc12 I have installed, but fail:

--->  Computing dependencies for libomp...
Error: Cannot install libgcc13 for the archs 'i386 x86_64' because
Error: its dependency libmpc cannot build for the required archs.

I suppose this is not a libomp issue, but a libgcc13 issue now?

clang 6.0 worked. Is that already a dependency issue? system clang is 8.0 here... so somehow strange.

No, this is not an issue with gcc13. The problem is with libomp, and started with 17.0.2. 17.0.1 for whatever reason was fine.

​https://ports.macports.org/port/libomp/details/

It affects OSX 10.11 and older.

[cjones051073 (Chris Jones)]

​https://github.com/macports/macports-ports/commit/1b993546449237c69624f2c5f77af9b6cd29688f

I cannot test locally so lets see what happens in the buildbots.

[cjones051073 (Chris Jones)]

This seems to have worked just fine, all buildbots 10.11 and older have now built libomp just fine

[eborisch (Eric A. Borisch)]

Thanks for getting to that, Chris!

[RobK88]

Thanks Chris! The boot-strapped solution is the way to go!

I uninstalled libomp and was able to reinstall it from source on Lion.

bash-3.2$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.7.5
BuildVersion:	11G63
bash-3.2$

sudo port uninstall libomp
Password:
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break:
 clang-15 @15.0.7_3
 clang-16 @16.0.6_2
 clang-9.0 @9.0.1_7
 clang-7.0 @7.1.0_3
 clang-11 @11.1.0_7
 clang-14 @14.0.6_2
Continue? [y/N]: Y
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating libomp @17.0.3_0+universal
--->  Cleaning libomp
--->  Uninstalling libomp @17.0.3_0+universal
--->  Cleaning libomp
bash-3.2$ 
 
bash-3.2$ sudo port -s install libomp
Password:
--->  Computing dependencies for libomp
--->  Fetching distfiles for libomp
--->  Verifying checksums for libomp
--->  Extracting libomp
--->  Applying patches to libomp
--->  Configuring libomp
--->  Building libomp                                    
--->  Staging libomp into destroot                       
--->  Installing libomp @17.0.3_0+universal
--->  Activating libomp @17.0.3_0+universal
--->  Cleaning libomp
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  libomp has the following notes:
    To use this OpenMP library:
     * For clang-3.8+, or clang-3.7 with +openmp variant:
        add "-fopenmp" during compilation / linking.
     * For clang-3.7 without +openmp variant, use:
        "-I/opt/local/include/libomp -L/opt/local/lib/libomp -fopenmp"
bash-3.2$

[kencu (Ken)]

when using clang-11-bootstrap as the compiler, someone should check to make sure than nothing in the built files or libraries links back into the libraries or tools supplied by clang-11-bootstrap.

it's unlikely for the vast majority of software to do that. It's conceivable that something might link back into those libraries, however, especially something like cctools or ld64 or similar, and that would have to be fixed, worked around, or accommodated if it did happen.

[RobK88]

@kencu -- It doesn't look like anything in the built files or libraries for libomp links back into the libraries or tools supplied by clang-11-bootstrap. See below. For completeness sake, I also looked at the header files. Nothing in there either.

The updated libomp port compiled using the clang-11-bootstrap looks good.

bash-3.2$ port contents libomp
Port libomp contains:
  /opt/local/include/libomp/omp-tools.h
  /opt/local/include/libomp/omp.h
  /opt/local/include/libomp/ompt.h
  /opt/local/lib/libomp/libgomp.dylib
  /opt/local/lib/libomp/libiomp5.dylib
  /opt/local/lib/libomp/libomp.dylib
  /opt/local/share/doc/libomp/LICENSE.TXT
  /opt/local/share/doc/libomp/README.txt
bash-3.2$ 
bash-3.2$ otool -L /opt/local/lib/libomp/libgomp.dylib
/opt/local/lib/libomp/libgomp.dylib:
	/opt/local/lib/libomp/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
bash-3.2$ 
bash-3.2$ otool -L /opt/local/lib/libomp/libiomp5.dylib
/opt/local/lib/libomp/libiomp5.dylib:
	/opt/local/lib/libomp/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
bash-3.2$ 
bash-3.2$ otool -L /opt/local/lib/libomp/libomp.dylib
/opt/local/lib/libomp/libomp.dylib:
	/opt/local/lib/libomp/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
bash-3.2$

[cjones051073 (Chris Jones)]

Thanks for checking.

I would though have been very surprised to find any dependencies as the regular clang-x ports are used as fallback build dependencies in a lot of cases as we have never had an issue like this, so it would have been weird for the clang 11 bootstrap port to be any different…

[kencu (Ken)]

As mentioned, the ties would more likely be pulled in by cctools or ld64, which are coming up for this treatment soon enough.

There, clang-11-bootstrap will be used to build some newish llvm and libtapi, and then cctools and ld64 will be built by clang-11-bootstrap to tie into those.

In the process, you have to make sure that the llvm in clang-11-bootstrap, or the libcxx in it, doesn't get pulled into the mixture and mess up the deps that way.

I know you can't actually test any of that, so just giving folks helping you a heads-up to avoid a mess.