graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

O. Hartmann ohartman at zedat.fu-berlin.de
Fri Oct 7 09:34:37 UTC 2016


Am Fri, 7 Oct 2016 02:00:34 -0700
Mark Millard <markmi at dsl-only.net> schrieb:

> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC 2016 . . .
> 
> . . . of having problems with not finding <stddef.h> during some port builds.
> 
> 
> Is there a difference in the -isystem command line options for c++ for the working vs.
> failing contexts?
> 
> I will presume that there is based on the following. . . (At least it gives you
> something to look into.)
> 
> 
> 
> 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:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213217
> 
> in particular Comment #2 from Dimitry Andric.
> 
> The problem is in how -isystem is used vs. what is needed for libc++ 3.8.0 .
> 
> From O. Hartmann's message text:
> 
> . . .
> > -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe -O3  
> . . .
> > 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> ^ ---  
> . . .
> > 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>  
> 
> 
> Dimitry wrote for this issue of <stddef.h> not being found:
> 
> > 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. :)  
> 
> There is more background/supporting information in that comment.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

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?

This is our/my src.conf:

#
CPUTYPE?=               native
#
CFLAGS+=                -O3
COPTFLAGS+=             -O3
#
#CXXFLAGS+=             -std=c++11
#
WITH_CLANG_FULL=        YES
WITH_CLANG_EXTRAS=      YES
WITH_LLDB=              YES


The /etc/makefile has

CPUTYPE?=native
COPTFLAGS+=-O3

I once compiled the systems (all of them without exceptions) with also
CXXFLAGS+=-std=c++11 set, but since the problems arose, I avoid that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20161007/599c4848/attachment.sig>


More information about the freebsd-ports mailing list