On 27 May 2016, at 17:32, Alan Somers <asom...@freebsd.org> wrote:
> 
> On Fri, May 27, 2016 at 9:28 AM, Dimitry Andric <d...@freebsd.org> wrote:
>> On 27 May 2016, at 16:49, Alan Somers <asom...@freebsd.org> wrote:
>>> 
>>> I think this change is breaking the build of C++ applications.  Below
>>> is a snippet of my amd64 buildworld, with the changes in D6564.  it
>>> built fine a few days ago.
...
>> It shouldn't, it passed a full make universe.  Do you have any special
>> settings in either make.conf or src.conf?  Or something other about your
>> build environment that is non-standard?
...
> 
> Ahh, but when you ran "make universe" there were not yet any C++
> things in lib/.  My patch adds a C++ library, and it fails when
> building the 32-bit version.  Here's the actual command that failed.
> I don't know why it failed, because
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/stddef.h
> _does_ exist.
> 
> c++ -m32 -DCOMPAT_32BIT -march=i686 -mmmx -msse -msse2
> -L/scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/lib32
> --sysroot=/scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32
> -B/scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/lib32
> -isystem /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include
>  -O2 -pipe -MD -MF.depend.consumer.o -MTconsumer.o
> -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith
> -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Qunused-arguments  -Wno-c++11-extensions
> -c /home/asomers/freebsd/head/lib/libdevdctl/consumer.cc -o consumer.o
> ...
> --- all_subdir_lib/libdevdctl ---
> In file included from /home/asomers/freebsd/head/lib/libdevdctl/event.cc:55:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/iostream:38:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/ios:216:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/__locale:15:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/string:439:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/algorithm:624:
> In file included from
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/initializer_list:47:
> /scratch/tmp/asomers/obj/home/asomers/freebsd/head/lib32/usr/include/c++/v1/cstddef:43:15:
> fatal error: 'stddef.h' file not found
> #include_next <stddef.h>
>              ^

I think what happens is the same what happened with some ports.  For
various reasons, the include path needs to be modified, and this causes
the header lookup to fail, when using #include_next<>.

Can you run the above command manually, but adding -v so it will print
out the full include paths it searches, and the order?

My guess is that either ${MAKEOBJDIRPREFIX}/usr/include/c++/v1 needs to
be added to the C++ include path, or some other path in the list is
missing, at least for C++ compilation.

-Dimitry

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to