Re: error: 'stddef.h' file not found on 12

On 2017-Nov-17, at 10:37 PM, Yuri <yuri_at_freebsd.org> wrote:

> On 11/16/17 22:29, Mark Millard wrote:
>> My guess is something is odd with your environment.
> 
> 
> It's not my environment, I keep getting these failure notifications from the central build. -)
> 
> 
> Ident:          $FreeBSD: head/net-im/ricochet/Makefile 454075 2017-11-12 19:19:37Z yuri $
> Log URL:http://beefy12.nyi.freebsd.org/data/head-amd64-default/p454296_s325882/logs/ricochet-1.1.4_9.log
> Build URL:http://beefy12.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p454296_s325882
> 
> Host OSVERSION: 1200050
> Jail OSVERSION: 1200054
> 

ricochet-1.1.4_9.log shows why the system files do not matter
if I understand right:

First off: what does include_next mean? Quoting
https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html :

. . . ‘#include_next’. It means, “Include the next file with this name”. This directive works like ‘#include’ except in searching for the specified file: it starts searching the list of header file directories after the directory in which the current file was found.

The command and error shown in the log are:

c++ -c -O2 -pipe -fstack-protector -fno-strict-aliasing -fPIC -fno-sanitize-recover -fstack-protector-strong -D_FORTIFY_SOURCE=2 -isystem /usr/local/include -std=gnu++11 -pthread -Wall -W -pthread -fPIC -DRICOCHET_NO_PORTABLE -DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -D_THREAD_SAFE -DQT_NO_DEBUG -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -Isrc -isystem /usr/include -I/usr/local/include -I/usr/local/include/qt5 -I/usr/local/include/qt5/QtQuick -I/usr/local/include/qt5/QtWidgets -I/usr/local/include/qt5/QtMultimedia -I/usr/local/include/qt5/QtGui -I/usr/local/include/qt5/QtQml -I/usr/local/include/qt5/QtNetwork -I/usr/local/include/qt5/QtCore -Irelease -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o release/main.o src/main.cpp
. . .
In file included from src/main.cpp:33:
In file included from src/ui/MainWindow.h:36:
In file included from /usr/local/include/qt5/QtCore/QObject:1:
In file included from /usr/local/include/qt5/QtCore/qobject.h:46:
In file included from /usr/local/include/qt5/QtCore/qobjectdefs.h:48:
In file included from /usr/local/include/qt5/QtCore/qnamespace.h:43:
In file included from /usr/local/include/qt5/QtCore/qglobal.h:45:
/usr/include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
              ^~~~~~~~~~

As I understand this:

/usr/include/c++/v1/ is were cstddef was found.

So the #include_next will only look later in the search
directory list.

The part of the search list on the command line
suggests that the only explicit reference to the
system trees has already been largely processed
by that point:

-isystem /usr/local/include
-I.
-Isrc
-isystem /usr/include   (<<<<=====)
-I/usr/local/include
-I/usr/local/include/qt5
-I/usr/local/include/qt5/QtQuick
-I/usr/local/include/qt5/QtWidgets
-I/usr/local/include/qt5/QtMultimedia
-I/usr/local/include/qt5/QtGui
-I/usr/local/include/qt5/QtQml
-I/usr/local/include/qt5/QtNetwork
-I/usr/local/include/qt5/QtCore
-Irelease
-I/usr/local/include
-I/usr/local/lib/qt5/mkspecs/freebsd-clang

It would be nice to see a dump of the actual
search path involved according to the compiler.
But I suspect it would show that for the
directory subset in involved in:

# find /usr/include -name stddef.h -print | more
/usr/include/c++/v1/tr1/stddef.h
/usr/include/c++/v1/stddef.h
/usr/include/sys/stddef.h
/usr/include/stddef.h

but that is actually searched by default
for the above c++ command is actually in
the directory relative order:

/usr/include/
. . .
/usr/include/c++/v1/

(no tr1 search by default)
(sys needing to be explicit). That means
that searching after /usr/include/c++/v1/
would not find stddef.h if I'm right.


I also expect that if the server executed a:

# find /usr/include -name stddef.h -print

just before the c++ command it would show that
the stddef.h files exist here I've reported.

===
Mark Millard
markmi at dsl-only.net