Bug 239539 - graphics/hugin: build fails with c++: error: unsupported argument 'libomp -I/usr/local/include -L/usr/local/lib' to option 'fopenmp='
Summary: graphics/hugin: build fails with c++: error: unsupported argument 'libomp -I...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Greg Lehey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-30 19:28 UTC by Martin Birgmeier
Modified: 2020-05-10 18:09 UTC (History)
0 users

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


Attachments
result of running "cd /usr/ports/graphics/openmp && make" (17.60 KB, text/plain)
2019-07-30 19:28 UTC, Martin Birgmeier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2019-07-30 19:28:29 UTC
Created attachment 206162 [details]
result of running "cd /usr/ports/graphics/openmp && make"

Scenario:
- FreeBSD 12.0 amd64
- rebuilding hugin after latest version bump (due to gcc8 -> gcc9 switch)

Result:
- The build fails right at the beginning with "c++: error: unsupported argument 'libomp  -I/usr/local/include -L/usr/local/lib' to option 'fopenmp='"
- logfile attached

It seems that the c compiler should understand an option "-fopenmp=..." but cannot grok the inclusion of -I... and -L... in said option.
Comment 1 Martin Birgmeier 2019-07-31 19:34:07 UTC
I could restart and successfully run to completion the build after the initial failure by editing the file work/.build/build.ninja, removing the double quotes from all lines containing the pattern

    FLAGS =.*"-fopenmp

(in vi, using

:g/FLAGS =.*"-fopenmp/s/"//g

)

But this is a manual solution.

Somehow the ninja file generated (by CMake?) includes the openmp C flags using double quotes when it should not, but I could not (yet) find out where this happens.

-- Martin
Comment 2 Greg Lehey freebsd_committer 2020-05-04 05:21:19 UTC
Is this still an issue?  It seems that revision 507372 addresses the problem:

  Bump PORTREVISION for ports depending on the canonical version of GCC
  as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
  to GCC 9.1 under most circumstances now after revision 507371.

  This includes ports
   - with USE_GCC=yes or USE_GCC=any,
   - with USES=fortran,
   - using Mk/bsd.octave.mk which in turn features USES=fortran, and
   - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
     c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
  plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.

Since then we have also released a new version of Hugin, and I haven't heard of any further issues.
Comment 3 Martin Birgmeier 2020-05-10 18:09:18 UTC
This seems to be fixed, the recent build of hugin-2019.2.0_1 went through without glitches.

-- Martin