Date: Fri, 17 Nov 2017 23:20:04 -0800 From: Mark Millard <markmi@dsl-only.net> To: yuri@freebsd.org Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: error: 'stddef.h' file not found on 12 Message-ID: <159C9C99-95C1-4A0E-B0D2-5AAD419260D0@dsl-only.net> In-Reply-To: <0bc65052-cbbd-3133-fa38-08cfb0d8c657@freebsd.org> References: <99B15AAD-4C7E-4A8B-8D2D-8126BF5976B6@dsl-only.net> <0bc65052-cbbd-3133-fa38-08cfb0d8c657@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Nov-17, at 10:37 PM, Yuri <yuri@freebsd.org> wrote: > On 11/16/17 22:29, Mark Millard wrote: >> My guess is something is odd with your environment. >=20 >=20 > It's not my environment, I keep getting these failure notifications = from the central build. -) >=20 >=20 > 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=3Dhead-amd64-defa= ult&build=3Dp454296_s325882 >=20 > Host OSVERSION: 1200050 > Jail OSVERSION: 1200054 >=20 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 : . . . =E2=80=98#include_next=E2=80=99. It means, =E2=80=9CInclude the = next file with this name=E2=80=9D. This directive works like = =E2=80=98#include=E2=80=99 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=3D2 = -isystem /usr/local/include -std=3Dgnu++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 (<<<<=3D=3D=3D=3D=3D) -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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?159C9C99-95C1-4A0E-B0D2-5AAD419260D0>