From owner-freebsd-ports@freebsd.org Fri Oct 7 10:45:39 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8017BC02262 for ; Fri, 7 Oct 2016 10:45:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-69.reflexion.net [208.70.210.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40740B57 for ; Fri, 7 Oct 2016 10:45:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28692 invoked from network); 7 Oct 2016 10:46:25 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2016 10:46:25 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Fri, 07 Oct 2016 06:45:37 -0400 (EDT) Received: (qmail 706 invoked from network); 7 Oct 2016 10:45:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2016 10:45:36 -0000 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 5CACAEC8EEC; Fri, 7 Oct 2016 03:45:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found From: Mark Millard In-Reply-To: <20161007113426.382cc416.ohartman@zedat.fu-berlin.de> Date: Fri, 7 Oct 2016 03:45:30 -0700 Cc: FreeBSD Ports , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <35CF5A82-3949-4E8A-9F97-01D2D03F24B2@dsl-only.net> References: <66A820DB-DAE0-41F6-BF36-4BB3C1AD465E@dsl-only.net> <20161007113426.382cc416.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 10:45:39 -0000 On 2016-Oct-7, at 2:34 AM, O. Hartmann = wrote: > Am Fri, 7 Oct 2016 02:00:34 -0700 > Mark Millard 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 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 ^ --- =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 =20 >>=20 >>=20 >> Dimitry wrote for this issue of 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 = for more modern but the basic problem likely exists for all = target C++ vintages. libc++ 3.8.0 does use internally ( via #include ) and that in = turn uses ( via #include_next ): (The below are from a stable/11 -r306344 context.) > # grep cstddef /usr/include/c++/v1/* > /usr/include/c++/v1/__debug:# include > /usr/include/c++/v1/__refstring:#include > /usr/include/c++/v1/__tuple:#include > /usr/include/c++/v1/algorithm:#include > /usr/include/c++/v1/atomic:#include > /usr/include/c++/v1/bitset:#include > /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 > /usr/include/c++/v1/initializer_list:#include > /usr/include/c++/v1/iterator:#include > /usr/include/c++/v1/memory:#include > /usr/include/c++/v1/new:#include > /usr/include/c++/v1/random:#include > /usr/include/c++/v1/thread:#include > Binary file /usr/include/c++/v1/tr1 matches > /usr/include/c++/v1/tuple:#include > /usr/include/c++/v1/type_traits:#include > /usr/include/c++/v1/typeinfo:#include > /usr/include/c++/v1/valarray:#include > # grep stddef.h /usr/include/c++/v1/* > /usr/include/c++/v1/cstddef:// Don't include our own ; we = don't want to declare ::nullptr_t. > /usr/include/c++/v1/cstddef:#include_next > /usr/include/c++/v1/cstddef:// Re-use the compiler's = max_align_t where possible. > /usr/include/c++/v1/cxxabi.h:#include > /usr/include/c++/v1/stddef.h://=3D=3D=3D--------------------------- = stddef.h ---------------------------------=3D=3D=3D// > /usr/include/c++/v1/stddef.h:#include_next > /usr/include/c++/v1/stddef.h: stddef.h synopsis > /usr/include/c++/v1/stddef.h:#include_next > /usr/include/c++/v1/stddef.h:// Re-use the compiler's = max_align_t where possible. > Binary file /usr/include/c++/v1/tr1 matches cxxabi.h also uses ( 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