Date: Fri, 7 Oct 2016 02:31:54 -0700 From: Mark Millard <markmi@dsl-only.net> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: FreeBSD Ports <freebsd-ports@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found Message-ID: <DEC9934D-1D77-4A7E-ACEF-1C737C9967CD@dsl-only.net> In-Reply-To: <20161007111459.164d5be7.ohartman@zedat.fu-berlin.de> References: <66A820DB-DAE0-41F6-BF36-4BB3C1AD465E@dsl-only.net> <20161007111459.164d5be7.ohartman@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Oct-7, at 2:14 AM, O. Hartmann <ohartman@zedat.fu-berlin.de> = wrote: >=20 > Am Fri, 7 Oct 2016 02:00:34 -0700 > Mark Millard <markmi@dsl-only.net> schrieb: >=20 >> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 = 08:26:27 UTC 2016 . . . >>=20 >> . . . of having problems with not finding <stddef.h> during some port = builds. >>=20 >>=20 >> Is there a difference in the -isystem command line options for c++ = for the working vs. >> failing contexts? >>=20 >> I will presume that there is based on the following. . . (At least it = gives you >> something to look into.) >>=20 >>=20 >>=20 >> The issue is not specific to just graphics/opencv-core and = graphics/blender ports: >> others also have problems with the use of -isystem for C++ compiles. = See: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213217 >>=20 >> in particular Comment #2 from Dimitry Andric. >>=20 >> The problem is in how -isystem is used vs. what is needed for libc++ = 3.8.0 . >>=20 >> =46rom O. Hartmann's message text: >>=20 >> . . . >>> -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 = -pipe -O3 =20 >> . . . >>> In file included from /usr/include/c++/v1/algorithm:624: In file = included >>> from /usr/include/c++/v1/initializer_list:47: = /usr/include/c++/v1/cstddef:43:15: fatal >>> error: 'stddef.h' file not found #include_next <stddef.h> ^ --- =20 >> . . . >>> In file included from /usr/include/c++/v1/algorithm:624: In file = included >>> from /usr/include/c++/v1/initializer_list:47: = /usr/include/c++/v1/cstddef:43:15: fatal >>> error: 'stddef.h' file not found #include_next <stddef.h> =20 >>=20 >>=20 >> Dimitry wrote for this issue of <stddef.h> not being found: >>=20 >>> Summary: If for some reason you must completely rebuild the header = search path >>> from scratch, you need to add -isystem /usr/include/c++/v1 *before* = -isystem >>> /usr/include. But it is better not to do this at all. :) =20 >>=20 >> There is more background/supporting information in that comment. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > Hello Mark, >=20 > thanks a lot for the hint. >=20 > I can not fathom - at the moment - what is different on the two = failing systems compared > to the non-failing ones. There must be something changing the order of = how the include > path is searched now Do the log files from the various working systems show any differences = in the -isystem sequence compared to the failing ones (for the same = source file being compiled)? It might be appropriate for your submittals (buszizlla and list) to also = include extractions of a working context's -isystem sequence vs. a = failing context's -isystem sequence for compiling the same source file. = (Your list submittal already showed an example of the failing -isystem = sequence, one that matches what Dimitry A. reports: So expected to = fail.) The working -isystem sequence one is not currently shown, at = least in the list submittal.) If both types of contexts have the same -isystem sequence then something = more is likely going on. But then showing examples of the matching log = file text for the -isystem sequences for the two types of contexts would = then be appropriate to identify the problem as unique. > - presumably I understood Dimitry Andric comment right (who explains = the problem very good > for my taste). >=20 > I will make a reference to Dimitri's comment on both PRs I filed. >=20 > Oliver =3D=3D=3D Mark Millard markmi@dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DEC9934D-1D77-4A7E-ACEF-1C737C9967CD>