Date: Fri, 7 Oct 2016 03:45:30 -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: <35CF5A82-3949-4E8A-9F97-01D2D03F24B2@dsl-only.net> In-Reply-To: <20161007113426.382cc416.ohartman@zedat.fu-berlin.de> References: <66A820DB-DAE0-41F6-BF36-4BB3C1AD465E@dsl-only.net> <20161007113426.382cc416.ohartman@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Oct-7, at 2:34 AM, O. Hartmann <ohartman at zedat.fu-berlin.de> = wrote: > Am Fri, 7 Oct 2016 02:00:34 -0700 > Mark Millard <markmi at 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 > I'd like to mention, that I do updates and recompilation of the system = on a almost daily > basis. Might it be possible thta I hit some transitional effects in = the toolchain? >=20 I've not seen any relevant svn-src-stable-11 or svn-src-head notices for = clang 3.8.0 or libc++ 3.8.0 changes in recent times (at least that I = remember). 3.9.0 has not moved to head yet. That would appear to leave = command line generation by other parts of the build environment for what = might vary. I do not remember anything for that either. > This is our/my src.conf: >=20 > # > CPUTYPE?=3D native > # > CFLAGS+=3D -O3 > COPTFLAGS+=3D -O3 > # > #CXXFLAGS+=3D -std=3Dc++11 > # > WITH_CLANG_FULL=3D YES > WITH_CLANG_EXTRAS=3D YES > WITH_LLDB=3D YES >=20 >=20 > The /etc/makefile has >=20 > CPUTYPE?=3Dnative > COPTFLAGS+=3D-O3 >=20 > I once compiled the systems (all of them without exceptions) with also > CXXFLAGS+=3D-std=3Dc++11 set, but since the problems arose, I avoid = that. I do not expect that Dimitry A.'s comments about -isystem and the search = paths vary much based on -std=3Dc++11 , -std=3Dc++14 , or older/other = -std=3D??? variants compiled by clang 3.8.0. It is just that libc++ = 3.8.0 is in use if I understand correctly. (libc++ auto adapts to the = -std=3D??? target.) May be there is somewhat more internal use of = <stddef.h> for more modern but the basic problem likely exists for all = target C++ vintages. libc++ 3.8.0 does use <cstddef> internally ( via #include ) and that in = turn uses <stddef.h> ( via #include_next ): (The below are from a stable/11 -r306344 context.) > # grep cstddef /usr/include/c++/v1/* > /usr/include/c++/v1/__debug:# include <cstddef> > /usr/include/c++/v1/__refstring:#include <cstddef> > /usr/include/c++/v1/__tuple:#include <cstddef> > /usr/include/c++/v1/algorithm:#include <cstddef> > /usr/include/c++/v1/atomic:#include <cstddef> > /usr/include/c++/v1/bitset:#include <cstddef> > /usr/include/c++/v1/cstddef://=3D=3D=3D--------------------------- = cstddef ----------------------------------=3D=3D=3D// > /usr/include/c++/v1/cstddef: cstddef synopsis > /usr/include/c++/v1/exception:#include <cstddef> > /usr/include/c++/v1/initializer_list:#include <cstddef> > /usr/include/c++/v1/iterator:#include <cstddef> > /usr/include/c++/v1/memory:#include <cstddef> > /usr/include/c++/v1/new:#include <cstddef> > /usr/include/c++/v1/random:#include <cstddef> > /usr/include/c++/v1/thread:#include <cstddef> > Binary file /usr/include/c++/v1/tr1 matches > /usr/include/c++/v1/tuple:#include <cstddef> > /usr/include/c++/v1/type_traits:#include <cstddef> > /usr/include/c++/v1/typeinfo:#include <cstddef> > /usr/include/c++/v1/valarray:#include <cstddef> > # grep stddef.h /usr/include/c++/v1/* > /usr/include/c++/v1/cstddef:// Don't include our own <stddef.h>; we = don't want to declare ::nullptr_t. > /usr/include/c++/v1/cstddef:#include_next <stddef.h> > /usr/include/c++/v1/cstddef:// Re-use the compiler's <stddef.h> = max_align_t where possible. > /usr/include/c++/v1/cxxabi.h:#include <stddef.h> > /usr/include/c++/v1/stddef.h://=3D=3D=3D--------------------------- = stddef.h ---------------------------------=3D=3D=3D// > /usr/include/c++/v1/stddef.h:#include_next <stddef.h> > /usr/include/c++/v1/stddef.h: stddef.h synopsis > /usr/include/c++/v1/stddef.h:#include_next <stddef.h> > /usr/include/c++/v1/stddef.h:// Re-use the compiler's <stddef.h> = max_align_t where possible. > Binary file /usr/include/c++/v1/tr1 matches cxxabi.h also uses <stddef.h> ( see above via #include ). Even stddef.h = uses stddef.h --but via #include_next . So it appears that having a bad -isystem sequence is fairly likely to = get this problem when libc++ 3.8.0 headers are in use. Some libc++ = header(s) may be in use implicitly even if there are no explicit = #include's of libc++ headers in the code referenced via the c++ = compiler's command line. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35CF5A82-3949-4E8A-9F97-01D2D03F24B2>