libarchive @3.5.2: ld: library not found for -lgomp

[catap (Kirill A. Korinsky)]

L/opt/local/lib /opt/local/lib/libiconv.dylib /opt/local/lib/liblzo2.dylib /opt/local/lib/liblzma.dylib -lzstd -llz4 /opt/local/lib/libcharset.dylib /opt/local/lib/libb2.dylib -lbz2 -lz /opt/local/lib/libxml2.dylib  -Os -arch i386 -Wl,-headerpad_max_install_names -arch i386   -pthread -fopenmp -install_name  /opt/local/lib/libarchive.13.dylib -compatibility_version 19 -current_version 19.2 -Wl,-single_module
clang: warning: argument unused during compilation: '-pthread'
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libarchive.la] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_archivers_libarchive/libarchive/work/libarchive-3.5.2'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_archivers_libarchive/libarchive/work/libarchive-3.5.2'
Command failed:  cd "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_archivers_libarchive/libarchive/work/libarchive-3.5.2" && /usr/bin/make -j4 -w all 
Exit code: 2

​https://build.macports.org/builders/ports-10.6_i386-builder/builds/46512/steps/install-port/logs/stdio

[tobypeterson]

I don't know how to resolve this. It's not even using -lgomp in the link line. Maybe related to -fopenmp - but why is it using that?!

[tobypeterson]

And the only change was to add the libb2 dependency.

[kencu (Ken)]

It will probably be testing to see if the -fopenmp flag is supported, (which clang-9.0 does support, used by 10.6), and if it is then it will probably misfire and think it is running on gcc and force -lgomp in somehow or another as the link library, which is wrong.

But as only 0.0001% of MacOS users use compilers that support -fopenmp nobody will have debugged this before.

We see something much the same happen with ImageMagick here #57009

Perhaps you might repro this on any system forcing macports-clang-9.0 as the compiler?

[kencu (Ken)]

well, I should look more before I comment I guess.

It is trying to build with

/opt/local/bin/clang-mp-3.7

and clang-3.7 does support the -fopenmp flag, but most likely it only does it correctly when building with -stdlib=libc++ if the openmp variant is selected, which we do not do by default.

​https://github.com/macports/macports-ports/blob/f2ec6c01a76b9dc42576908cc812247a6de10399/lang/llvm-3.7/Portfile#L449

So clang-3.7 is therefore most likely trying to support openmp but doing it wrong, it appears, and clang-3.7 is probably passing the -lgomp itself internally, if we were to dig in a bit on what it does when the openmp variant is not selected, vs what clang-3.7 does when the openmp variant is selected.

In any event, the right thing to do is probably to force openmp off for the build unless it is (someday) specifically turned on by some general openmp fix in MacPorts.

[jmroot (Joshua Root)]

Replying to tobypeterson:

And the only change was to add the libb2 dependency.

And the flag is in fact coming from libb2.

% grep openmp /opt/local/lib/libb2.la   
inherited_linker_flags='  -fopenmp'

[jmroot (Joshua Root)]

In c3b1cbfdbc57023f304f595163ef36d20f27c829/macports-ports (master):

libb2: ensure openmp support is disabled

The flag can leak into dependents where it often doesn't work.

Fixes: #64116

[kencu (Ken)]

for those eager lately to enable openmp in various ports, this is the kind of unexpected stuff that comes up.

macports has no mechanism yet for libb2 to inform it's consumers that a proper openmp-supporting compiler is needed.

[tobypeterson]

Didn't see that one coming. Nice find!