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

[O. Hartmann]

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

> 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)?

I have not checked that yet, but it is an excellent advice. I have a notebook compiling
both ports perfectly.

> 
> 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.)

As soon I find something different, I'll do.

But this will take a while as I'm not in lab at themoment.

> 
> 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

-------------- 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/ebd065bc/attachment.sig>