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

[O. Hartmann]

Am Fri, 7 Oct 2016 14:03:52 +0200
Dimitry Andric  schrieb:

> On 07 Oct 2016, at 13:59, Dimitry Andric  wrote:
> > 
> > On 07 Oct 2016, at 13:43, O. Hartmann  wrote:  
> ...
> >> YES :-(
> >> 
> >> /usr/include/include does exist ...  
> > 
> > Right, so that is pretty strange.  Maybe it was an artefact of some
> > failed installation?  In any case, I would blow it away.
> > 
> > Btw, it looks like the eigen port uses pkgconfig, can you please post
> > the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?  
> 
> For reference, on my system where I just freshly compiled eigen3, the
> contents is this:
> 
> 
> prefix=/usr/local
> exec_prefix=${prefix}
> 
> Name: Eigen3
> Description: A C++ template library for linear algebra: vectors, matrices, 
> and related
> algorithms Requires:
> Version: 3.2.10
> Libs:
> Cflags: -I${prefix}/include/eigen3
> 
> 
> -Dimitry
> 

Mine looks the same:
---
prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related
algorithms Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3
---


pgpurtt4JBOGf.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

Am Fri, 7 Oct 2016 13:59:05 +0200
Dimitry Andric  schrieb:

> On 07 Oct 2016, at 13:43, O. Hartmann  wrote:
> > 
> > Am Fri, 7 Oct 2016 13:27:19 +0200
> > Dimitry Andric  schrieb:  
> >> On 07 Oct 2016, at 10:26, O. Hartmann  wrote: 
> >>  
> ...
> >>> In file included
> >>> from 
> >>> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> >>> 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   
> >> 
> >> So for some reason, on your system, the compilation flags include
> >> -isystem /usr/include/include, which is rather strange.  I would not
> >> expect this to break compilation in the fashion you are seeing.  Do you
> >> have an /usr/include/include directory on your system, by any chance?  
> > 
> > YES :-(
> > 
> > /usr/include/include does exist ...  
> 
> Right, so that is pretty strange.  Maybe it was an artefact of some
> failed installation?  In any case, I would blow it away.

Within the past years, I slide from one CURRENT to the next. There was no 
accdent as far
as I can recall, but due to the fact I do quite often a recompilation of the 
system, the
likelyhood of hitting the fan (or problems) is quite high. I gues this is a 
remnant of
some problems not visible to me.


I blew the /usr/include/include folder, but then the system rejected to 
buildworld. I had
to reinstall world, did a complete buildworld/buildkernel with recent sources 
and started
recompilation of updated ports. Now, graphics/opencv2-core compiles!

Thank you very much. Quite impressive!

> 
> Btw, it looks like the eigen port uses pkgconfig, can you please post
> the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?
> 
> -Dimitry
> 

Content of /usr/local/libdata/pkgconfig/eigen3.pc:

prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related
algorithms Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3

Thank you very much and kind regards,

Oliver



pgpMOt6T5uwuW.pgp
Description: OpenPGP digital signature

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

[Dimitry Andric]

On 07 Oct 2016, at 13:59, Dimitry Andric  wrote:
> 
> On 07 Oct 2016, at 13:43, O. Hartmann  wrote:
...
>> YES :-(
>> 
>> /usr/include/include does exist ...
> 
> Right, so that is pretty strange.  Maybe it was an artefact of some
> failed installation?  In any case, I would blow it away.
> 
> Btw, it looks like the eigen port uses pkgconfig, can you please post
> the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?

For reference, on my system where I just freshly compiled eigen3, the
contents is this:


prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related algorithms
Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3


-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Dimitry Andric]

On 07 Oct 2016, at 13:43, O. Hartmann  wrote:
> 
> Am Fri, 7 Oct 2016 13:27:19 +0200
> Dimitry Andric  schrieb:
>> On 07 Oct 2016, at 10:26, O. Hartmann  wrote:
...
>>> In file included
>>> from 
>>> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
>>> 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 
>> 
>> So for some reason, on your system, the compilation flags include
>> -isystem /usr/include/include, which is rather strange.  I would not
>> expect this to break compilation in the fashion you are seeing.  Do you
>> have an /usr/include/include directory on your system, by any chance?
> 
> YES :-(
> 
> /usr/include/include does exist ...

Right, so that is pretty strange.  Maybe it was an artefact of some
failed installation?  In any case, I would blow it away.

Btw, it looks like the eigen port uses pkgconfig, can you please post
the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[O. Hartmann]

Am Fri, 7 Oct 2016 13:27:19 +0200
Dimitry Andric  schrieb:

> On 07 Oct 2016, at 10:26, O. Hartmann  wrote:
> > 
> > I'm being haunted by this error on two CURRENT systems, while several other 
> > CURRENT
> > systems with identical src.conf and make.conf are not affected, please see 
> > below.  
> ...
> > cd /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core && 
> > /usr/bin/c++
> > -DCVAPI_EXPORTS
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/dynamicuda/include
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1
> > -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe 
> > -O3
> > -march=native -fstack-protector -fno-strict-aliasing   -fsigned-char -W
> > -Werror=return-type -Werror=address -Werror=sequence-point -Wformat
> > -Werror=format-security -Wmissing-declarations -Wmissing-prototypes
> > -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow 
> > -Wsign-promo
> > -Wno-narrowing -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args
> > -Wno-array-bounds -fdiagnostics-show-option -Wno-long-long -pthread
> > -fomit-frame-pointer -msse -msse2 -mavx -mavx2 -ffunction-sections -O2 
> > -pipe -O3
> > -march=native -fstack-protector -fno-strict-aliasing  -DNDEBUG -fPIC -o
> > CMakeFiles/opencv_core.dir/src/arithm.cpp.o  
> ...
> > In file included
> > from 
> > /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> > 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   
> 
> So for some reason, on your system, the compilation flags include
> -isystem /usr/include/include, which is rather strange.  I would not
> expect this to break compilation in the fashion you are seeing.  Do you
> have an /usr/include/include directory on your system, by any chance?

YES :-(

/usr/include/include does exist ... 

> 
> That said, for me graphics/opencv2-core compiles just fine, and the
> compilation flags only have an -isystem option to point at the
> /usr/local/include/eigen3 directory.
> 
> Maybe the problem lies in the eigen3 port?  I assume this will have a
> pkg-config file, or some other way at getting the required CFLAGS and
> CXXFLAGS for using it.
> 
> -Dimitry
> 



pgpneRHRk0FK3.pgp
Description: OpenPGP digital signature

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

[Dimitry Andric]

On 07 Oct 2016, at 10:26, O. Hartmann  wrote:
> 
> I'm being haunted by this error on two CURRENT systems, while several other 
> CURRENT
> systems with identical src.conf and make.conf are not affected, please see 
> below.
...
> cd /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core && 
> /usr/bin/c++
> -DCVAPI_EXPORTS
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/dynamicuda/include
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1
> -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe -O3
> -march=native -fstack-protector -fno-strict-aliasing   -fsigned-char -W
> -Werror=return-type -Werror=address -Werror=sequence-point -Wformat
> -Werror=format-security -Wmissing-declarations -Wmissing-prototypes 
> -Wstrict-prototypes
> -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing
> -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-array-bounds
> -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse 
> -msse2 -mavx
> -mavx2 -ffunction-sections -O2 -pipe -O3 -march=native -fstack-protector
> -fno-strict-aliasing  -DNDEBUG -fPIC -o 
> CMakeFiles/opencv_core.dir/src/arithm.cpp.o
...
> In file included
> from 
> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> 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 

So for some reason, on your system, the compilation flags include
-isystem /usr/include/include, which is rather strange.  I would not
expect this to break compilation in the fashion you are seeing.  Do you
have an /usr/include/include directory on your system, by any chance?

That said, for me graphics/opencv2-core compiles just fine, and the
compilation flags only have an -isystem option to point at the
/usr/local/include/eigen3 directory.

Maybe the problem lies in the eigen3 port?  I assume this will have a
pkg-config file, or some other way at getting the required CFLAGS and
CXXFLAGS for using it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Mark Millard]

On 2016-Oct-7, at 2:34 AM, O. Hartmann  wrote:

> Am Fri, 7 Oct 2016 02:00:34 -0700
> Mark Millard  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  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  ^ ---  
>> . . .
>>> 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   
>> 
>> 
>> Dimitry wrote for this issue of  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  for more modern but the basic problem 
likely exists for all target C++ vintages.

libc++ 3.8.0 does use  internally ( via #include ) and that in turn 
uses  ( via #include_next ):

(The below are from a stable/11 -r306344 context.)

> # grep cstddef /usr/include/c++/v1/*
> /usr/include/c++/v1/__debug:#   include 
> /usr/include/c++/v1/__refstring:#include 
> /usr/include/c++/v1/__tuple:#include 
> /usr/include/c++/v1/algorithm:#include 
> /usr/include/c++/v1/atomic:#include 
> /usr/include/c++/v1/bitset:#include 
> /usr/include/c++/v1/cstddef://===--- cstddef 
> --===//
> /usr/include/c++/v1/cstddef:cstddef synopsis
> /usr/include/c++/v1/exception:#include 
> /usr/include/c++/v1/initializer_list:#include 
> /usr/include/c++/v1/iterator:#include 
> /usr/include/c++/v1/memory:#include 
> /usr/include/c++/v1/new:#include 
> /usr/include/c++/v1/random:#include 
> /usr/include/c++/v1/thread:#include 
> Binary file /usr/include/c++/v1/tr1 matches
> /usr/include/c++/v1/tuple:#include 
> /usr/include/c++/v1/type_traits:#include 
> /usr/include/c++/v1/typeinfo:#include 
> /usr/include/c++/v1/valarray:#include 


> # grep stddef.h /usr/include/c++/v1/*
> /usr/include/c++/v1/cstddef:// Don't include our own ; we don't 
> want to declare ::nullptr_t.
> /usr/include/c++/v1/cstddef:#include_next 
> /usr/include/c++/v1/cstddef:// Re-use the compiler's  max_align_t 
> where possible.
> /usr/include/c++/v1/cxxabi.h:#include 
> /usr/include/c++/v1/stddef.h://===--- stddef.h 
> -===//
> /usr/include/c++/v1/stddef.h:#include_next 
> 

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

[Mark Millard]

On 2016-Oct-7, at 2:14 AM, O. Hartmann  wrote:
> 
> Am Fri, 7 Oct 2016 02:00:34 -0700
> Mark Millard  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  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  ^ ---  
>> . . .
>>> 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   
>> 
>> 
>> Dimitry wrote for this issue of  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
mar...@dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 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  schrieb:

> On 2016-Oct-7, at 2:14 AM, O. Hartmann  wrote:
> > 
> > Am Fri, 7 Oct 2016 02:00:34 -0700
> > Mark Millard  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  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  ^ ---
> >> . . .  
> >>> 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 
> >> 
> >> 
> >> Dimitry wrote for this issue of  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
> mar...@dsl-only.net



pgp5E4ikOiedp.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

Am Fri, 7 Oct 2016 02:00:34 -0700
Mark Millard  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  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  ^ ---  
> . . .
> > 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   
> 
> 
> Dimitry wrote for this issue of  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.


pgp65MrE2t3oo.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

Am Fri, 7 Oct 2016 02:00:34 -0700
Mark Millard  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  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  ^ ---  
> . . .
> > 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   
> 
> 
> Dimitry wrote for this issue of  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
- 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


pgpGvh4tB1RU1.pgp
Description: OpenPGP digital signature

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

[Mark Millard]

O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC 2016 
. . .

. . . of having problems with not finding  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  ^ ---
. . .
> 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 


Dimitry wrote for this issue of  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

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"