On 2017-Nov-17, at 10:37 PM, Yuri <y...@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 $
> 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
. . . ‘#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/QtNetwork -I/usr/local/include/qt5/QtCore -Irelease
-I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o
. . .
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
As I understand this:
/usr/include/c++/v1/ is were cstddef was found.
So the #include_next will only look later in the search
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/include (<<<<=====)
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
but that is actually searched by default
for the above c++ command is actually in
the directory relative order:
. . .
(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.
markmi at dsl-only.net
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"