From owner-freebsd-current@freebsd.org Sat Nov 18 07:26:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83B12DF0BD0 for ; Sat, 18 Nov 2017 07:26:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-125.reflexion.net [208.70.210.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 495646667E for ; Sat, 18 Nov 2017 07:26:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26492 invoked from network); 18 Nov 2017 07:20:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Nov 2017 07:20:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 18 Nov 2017 02:20:06 -0500 (EST) Received: (qmail 32508 invoked from network); 18 Nov 2017 07:20:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Nov 2017 07:20:05 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 49D97EC8014; Fri, 17 Nov 2017 23:20:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: error: 'stddef.h' file not found on 12 From: Mark Millard In-Reply-To: <0bc65052-cbbd-3133-fa38-08cfb0d8c657@freebsd.org> Date: Fri, 17 Nov 2017 23:20:04 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <159C9C99-95C1-4A0E-B0D2-5AAD419260D0@dsl-only.net> References: <99B15AAD-4C7E-4A8B-8D2D-8126BF5976B6@dsl-only.net> <0bc65052-cbbd-3133-fa38-08cfb0d8c657@freebsd.org> To: yuri@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 07:26:53 -0000 On 2017-Nov-17, at 10:37 PM, Yuri 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 ^~~~~~~~~~ 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