Bug 233946 - graphics/ImageMagick6-nox11 /usr/bin/ld: cannot find -lomp
Summary: graphics/ImageMagick6-nox11 /usr/bin/ld: cannot find -lomp
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Koop Mast
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2018-12-11 22:21 UTC by gessel
Modified: 2019-08-31 07:07 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (kwm)


Attachments
Build log (859.30 KB, text/plain)
2019-08-31 07:03 UTC, fengshaun
no flags Details
`uname -a` and `/etc/make.conf` (166 bytes, text/plain)
2019-08-31 07:04 UTC, fengshaun
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gessel 2018-12-11 22:21:27 UTC
I'm having trouble compiling (portmaster) ImageMagick6-nox11-6.9.10.14_1,1 and ImageMagick7-nox11-7.0.8.14_1, v6 fails with "/usr/bin/ld: cannot find -lomp"

In both cases, the OPENMP option is NOT selected.  (#223518)  In ImageMagick6 the fail is

libtool: link: cc -shared  -fPIC -DPIC  coders/.libs/coders_dng_la-dng.o   -Wl,-rpath -Wl,/var/ports/usr/ports/graphics/ImageMagick6-nox11/work/ImageMagick-6.9.10-14/magick/.libs -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib magick/.libs/libMagickCore-6.so -lpthread -L/usr/local/lib -lfreetype -llqr-1 -lglib-2.0 -lintl -lfftw3 -lxml2 -llzma -lbz2 -lz /usr/local/lib/libltdl.so -lm -lraw_r -llcms2  -Oz -march=barcelona -mtune=barcelona -march=amdfam10 -fstack-protector -pthread -fstack-protector -fopenmp   -pthread -fopenmp -Wl,-soname -Wl,dng.so -Wl,-version-script -Wl,coders/.libs/dng.so-ver -o coders/.libs/dng.so
/usr/bin/ld: cannot find -lomp
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:5688: coders/dng.la] Error 1
gmake[2]: *** Waiting for unfinished jobs....


and in ImageMagick7 it is

10 -fstack-protector -pthread -fstack-protector   -pthread -Wl,-soname -Wl,dpx.so -Wl,-version-script -Wl,coders/.libs/dpx.so-ver -o coders/.libs/dpx.so
/usr/bin/ld: cannot find -lomp
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:6385: coders/dng.la] Error 1
gmake[2]: *** Waiting for unfinished jobs....

FreeBSD 11.2-RELEASE-p6 #0 r341740
Comment 1 gessel 2018-12-12 01:36:02 UTC
does not seem to be related to threads, tried all four permutations of THREADS and OPENMP to no avail.
Comment 2 gessel 2018-12-12 19:58:56 UTC
On this jail, the service that calls ImageMagick is www/nextcloud.  I can disable ImageMagick in the nextcloud config to get past the bug.  It is suboptimal, but works.
Comment 3 gessel 2018-12-13 01:18:23 UTC
c++ --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin
Comment 4 mikhail.rokhin 2018-12-19 18:04:23 UTC
Confirm the bug. Please, change the Importance to Affects Everyone.

It can't find 

/usr/local/llvm60/lib/ 
/usr/local/llvm70/lib/ 
/usr/local/llvm-devel/lib/ 

libomp.so properly, although it is in ldconfig path!!

But other ports having OpenMP option enabled find it properly.

Obviously, it local ImageMagick script failure.
Comment 5 mikhail.rokhin 2018-12-21 00:19:54 UTC
Obviously, it's local ImageMagick script failure for clang (llvm) -fopenmp parameter . What-so-ever OpenMP is checked or unchecked in options (make config) - it fails with built-in clang 7.0.1 for FBSD latest, 'cause there is no such lib for built-in llvm (clang), see bug #222858 . 

When GCC (GCC8) is used to compile, it succeeds with OpenMP option unchecked and checked.

When not built-in clang is used (llvm/clang 6) it succeeds.

ImageMagic needs more intellectual script detecting availability of -lomp at config stage and auto-disable it, whether it's unavailable (what-so-ever it's enabled by `make config`).
Comment 6 mikhail.rokhin 2018-12-21 00:57:17 UTC
ImageMagic needs more intellectual script detecting availability of -lomp at config stage and auto-disable it, whether it's unavailable (what-so-ever it's enabled by `make config`).

OR

Requiring as dependency extra LLVM OpenMP supporting port installed for clang compiler.
Comment 7 mikhail.rokhin 2018-12-21 15:45:18 UTC
Better approach could be so:

for `make config`

---OpenMP---
( ) Compile with the latest (not -devel) GCC
(*) Compile with the latest (not -devel) LLVM
---

for ImageMagick configuration script

try to `pkg ins ` latest compiler, whether it's been not installed yet (as we all know the very long compilation process for hours of such huge ports like GCC & LLVM),

if fails, try to compile it from ports and continue compil. of ImageMagick.

I'm very newbie and can not create such patch myself.

N.B. It's very good practice for any port: at first, try to meet dependencies with `pkg ins ...` (for huge ports at least).

Thank you for development.
Comment 8 mikhail.rokhin 2018-12-21 17:20:43 UTC
(In reply to gessel from comment #1)
You may try to install devel/openmp to use with built-in llvm , but in my case it led to other failure for 

- ImageMagick6 (6.9.10.16,1):

libtool: link: /usr/local/bin/nm -B coders/.libs/aai_la-aai.o ... > coders/.libs/aai.exp
eval: 1: Syntax error: "|" unexpected
Comment 9 nhoyle 2019-01-07 20:55:38 UTC
I also encountered an issue (unable to find -lomp) attempting to build (via poudriere) with OPENMP option set. Upon reviewing the Makefile, it appears that USES+= compiler:openmp is set, which, from reading Mk/Uses/compiler.mk, it appears should toggle gcc to be used. Nonetheless, it appeared from my build log that clang was being used. Clang/llvm (6.0.1, in base; 7 merges in direct support, but that's not what we have currently) wants the omp library, which is a separate install, whereas gcc uses -lgomp, which is part of the gcc install.

Changing the graphics/ImageMagick6 makefile to include USE_GCC=any instead of USES+=compiler:openmp successfully worked around this problem and built cleanly.

I also attempted using clang while adding "LIB_DEPENDS+=libomp.so:devel/openmp", which failed, with the error Mikhail noted. The output actually had "| |" as part of one of the build commands (a pipe to empty whitespace to another pipe). This is possibly a separate issue related to building with clang that should be tracked down, but forcing gcc as above works.
Comment 10 Tommy P 2019-04-12 18:51:54 UTC
I also encountered this error in poudriere on 11.2-RELEASE and 12.0-RELEASE:

/usr/bin/ld: cannot find -lomp
cc: error: linker command failed with exit code 1 (use -v to see invocation)

As @nhoyle suggested, I used:

USE_GCC=gcc8

since I have the port built.
Comment 11 Tommy P 2019-04-12 19:30:04 UTC
Just out of curiosity, I've compared ImageMagick6's Makefile vs ImageMagick7's, the only significant difference I see is:

USES=         compiler:c++11-lang

in the ImageMagick6's while ImageMagick7 doesn't have it.  When omitting that usage in ImageMagick6, ImageMagick6 failed to 'fetch' while ImageMagick7 builds OK.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-28 03:51:23 UTC
Both versions of the port/package are being produced successfully on the package building cluster (FreeBSD:12:amd64/latest), as of August 25, 2019

ImageMagick6-nox11-6.9.10.57,1.txz
ImageMagick7-nox11-7.0.8.57_1.txz

We need:

- Confirmation this issue is still present with the latest port/package versions

- System/environment information (as attachments, uname -a, pkg version -v, /etc/make.conf contents)

- Build logs exhibiting the failure (as attachments) 

- To understand/identify the conditions under which this issue is present
Comment 13 fengshaun 2019-08-31 07:03:56 UTC
Created attachment 207038 [details]
Build log

/usr/bin/ld: error: unable to find library -lomp
Comment 14 fengshaun 2019-08-31 07:04:31 UTC
Created attachment 207039 [details]
`uname -a` and `/etc/make.conf`
Comment 15 fengshaun 2019-08-31 07:07:20 UTC
Issue still persists on my machine with Freebsd 12.0-RELEASE and ports updated as of 2019-08-29, with openmp/threads set or unset. Using poudriere to build the pkg, so I'm not sure how helpful my host configuration is.