graphics/darktable: release 2.6.2_3 fails to build under ports-mgmt/synth due to OpenMP dependency causing synth's dependency check to fail. I have described the issue in detail on this thread: https://forums.freebsd.org/threads/synth-cannot-install-or-upgrade-darktable.72250/
which version of freebsd are you using? I suspect a bug in synth, can you provide the full build log from synth?
Same problem with poudriere. I am on 12.0.
(In reply to Alexandre C. Guimarães from comment #2) Sorry, that was an 11.2 jail.
Ignore my previous two comments. I was tring to install from the 12.0 jail. :-(
Created attachment 207389 [details] synth build log for darktable Please note the lines with "actual-package-depends: dependency on /usr/lib/libomp.so not registered (normal if it belongs to base)"
I'm on 11.3-RELEASE-p3
Hi! I couldn't reproduce a check or build failure locally. However, if I inspect the produced package, it doesn't require/depend on libomp.so. So there must be something wrong with that Makefile. I will keep you posted with my findings!
Thanks for the update! Here is my take on it: Did you use synth? I don't think the build fails. On my machine the package built successfully (under synth) and the .tgz file was generated. However, then synth checks for dependencies and fails on the dependency on libomp.so. The dependency check uses /usr/ports/Mk/Scripts/actual-package-depends.sh (with argument /usr/lib/libomp.so). In particular, the command pkg which -q /usr/lib/libomp.so is used to find a package providing libomp.so (sorry if I'm being pedantic). Since the lib is part of base no such package is found. The next command run is pkg query "\"%n\": {origin: \"%o\", version: \"%v\"}" "" with an empty string because no package is found, resulting in non-zero exit status. That's why synth fails the dependency check. Btw how did check for dependencies? I'm guessing pkg info -d? It won't show the dependency on libomp.so since it is provided by base and not ports. The built darktable binary does have a runtime dependency on openmp as seen by running ldd /usr/local/bin/darktable|grep -i libomp So, I think the Makefile is probably okay. It looks like a synth bug now IMHO.
To precise, the problem arises when you ask synth to install the package it just built. Because of the dependency check failure the new package file is deleted during the repository rebuild step and install fails. synth test graphics/darktable runs just fine.
Created attachment 207540 [details] Patch to simplify the dependency to libomp.so Hi! I couldn't reproduce the issue with FreeBSD 11.2, 11.3 or HEAD in Poudriere. However, I looked at other ports using OpenMP. Based on that, here is a patch which simplifies the dependency to libomp.so. Hopefully it will help you. Could you please test it?
FTR I tested with `poudriere testport` which also installs the package it built. I believe that's the equivalent to `synth test`.
Thanks again for the effort! I'll retest with this patch and report back. I think I need to report this to marino because I now believe the problem is with synth. Basically if there is any dependency on a library outside of ports in the same way as there is for limomp.so synth will fail.
FYI, I created this issue on github: https://github.com/jrmarino/synth/issues/168
Hello, apologies for the delay. I tested the patch. The solution is to move the dependency on openmp from base to ports, which the patch attempts. However, something is still not right because the build is finding and linking against libomp.so from the base system, even though openmp is being built and installed as a dependency from ports. So the dependency check in synth is still failing. How can we make the build pick up libomp.so from ports instead? Looks like we need to override /usr/lib with /usr/local/lib somewhere.
I think with the removal of the openmp port and openmp being only available from base, this could be considered overcome by events. Please comment and reopen this PR with new logs of a supported operating system version and a fully-updated ports tree, or fully updated 2020Q2.
Hi, confirming that I am no longer getting an error from synth, and the package is being successfully built. Thanks!