Date: Fri, 7 Oct 2016 11:38:01 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Mark Millard <markmi@dsl-only.net> 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: <20161007113801.1ba1bf08.ohartman@zedat.fu-berlin.de> In-Reply-To: <DEC9934D-1D77-4A7E-ACEF-1C737C9967CD@dsl-only.net> References: <66A820DB-DAE0-41F6-BF36-4BB3C1AD465E@dsl-only.net> <20161007111459.164d5be7.ohartman@zedat.fu-berlin.de> <DEC9934D-1D77-4A7E-ACEF-1C737C9967CD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/fPBqrqeJV0mB_SFsi6=2A1V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 7 Oct 2016 02:31:54 -0700 Mark Millard <markmi@dsl-only.net> schrieb: > On 2016-Oct-7, at 2:14 AM, O. Hartmann <ohartman@zedat.fu-berlin.de> wrot= e: > >=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/bl= ender ports: > >> others also have problems with the use of -isystem for C++ compiles. S= ee: > >>=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 > >> From O. Hartmann's message text: > >>=20 > >> . . . =20 > >>> -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 = -pipe -O3 =20 > >> . . . =20 > >>> In file included from /usr/include/c++/v1/algorithm:624: In file incl= uded > >>> from /usr/include/c++/v1/initializer_list:47: /usr/include/c++/v1/cst= ddef:43:15: > >>> fatal error: 'stddef.h' file not found #include_next <stddef.h> ^ ---= =20 > >> . . . =20 > >>> In file included from /usr/include/c++/v1/algorithm:624: In file incl= uded > >>> from /usr/include/c++/v1/initializer_list:47: /usr/include/c++/v1/cst= ddef: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 se= arch 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 > >=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 =20 >=20 > 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 com= piled)? I have not checked that yet, but it is an excellent advice. I have a notebo= ok compiling both ports perfectly. >=20 > It might be appropriate for your submittals (buszizlla and list) to also = include > extractions of a working context's -isystem sequence vs. a failing contex= t'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 sho= wn, at least > in the list submittal.) As soon I find something different, I'll do. But this will take a while as I'm not in lab at themoment. >=20 > 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 iden= tify the > problem as unique. >=20 >=20 > > - presumably I understood Dimitry Andric comment right (who explains th= e problem very > > good for my taste). > >=20 > > I will make a reference to Dimitri's comment on both PRs I filed. > >=20 > > Oliver =20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net --Sig_/fPBqrqeJV0mB_SFsi6=2A1V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX92z5AAoJEOgBcD7A/5N8TFkH/2b4CHDusDtdTf3GPa4IC+oI l05RizDpAwy4K1fcX5jv6kXT5DYshHAYl8uXOo9yP2WZyqxVerTy1oAZQDjT6agk lQusPBonZzio/id4Xr6frjDhyO04233+ZMz1itiSEMJRCeBoJOylGqDXUhKYriyP y/0e4HfSU3gvCOMO0cX6qOfpIO95Dahi6ra0Tlj1wLcNKOfameHk0k5IOxy4LNV0 lSidNw03RrkC7DRPRs3iYHLCN8DP7YMSU8EHhQRyISG04XLo4raHT1Emf+oK8qVt Cz/Ka5/gMwf1lPim6dCZL0hL0HdSkrI7Gn4mQ5iUNH+VHyziiQeDrJHsmBqI1d0= =pLrq -----END PGP SIGNATURE----- --Sig_/fPBqrqeJV0mB_SFsi6=2A1V--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161007113801.1ba1bf08.ohartman>