graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found
Mark Millard
markmi at dsl-only.net
Fri Oct 7 10:45:39 UTC 2016
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:
>
>> 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?
>
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:
>
> #
> 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.
I do not expect that Dimitry A.'s comments about -isystem and the search paths vary much based on -std=c++11 , -std=c++14 , or older/other -std=??? 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=??? 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://===--------------------------- cstddef ----------------------------------===//
> /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://===--------------------------- stddef.h ---------------------------------===//
> /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.
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ports
mailing list