graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found
Mark Millard
markmi at dsl-only.net
Fri Oct 7 09:38:44 UTC 2016
On 2016-Oct-7, at 2:14 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
>
> Hello Mark,
>
> thanks a lot for the hint.
>
> 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
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 compiled)?
It might be appropriate for your submittals (buszizlla and list) to also include extractions of a working context's -isystem sequence vs. a failing context'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 shown, at least in the list submittal.)
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 identify the problem as unique.
> - presumably I understood Dimitry Andric comment right (who explains the problem very good
> for my taste).
>
> I will make a reference to Dimitri's comment on both PRs I filed.
>
> Oliver
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ports
mailing list