From owner-freebsd-current@freebsd.org Mon Apr 9 03:54:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79F41F9DCDD for ; Mon, 9 Apr 2018 03:54:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB0A17F603 for ; Mon, 9 Apr 2018 03:54:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w393sjqm016812; Sun, 8 Apr 2018 20:54:45 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w393sjxl016811; Sun, 8 Apr 2018 20:54:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804090354.w393sjxl016811@pdx.rh.CN85.dnsmgr.net> Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <20180409015048.GB93747@www.zefox.net> To: bob prohaska Date: Sun, 8 Apr 2018 20:54:45 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Mon, 09 Apr 2018 03:54:50 -0000 > On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote: > > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > > > I am having a compile time issue for a patched that compiled fine on my > > > > r329294 system, but now failes to compile with what looks like a wrong > > > > header being included. > > > > > > > Might this be a cousin to the problem reported at > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ? > > > > > > In that kernel compile (on an RPi3) the compiler complains > > > > > > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > > > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > > > /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) > > > typedef __int_least16_t int_fast16_t; > > > > > > The reference to /usr/lib/clang/... seems a bit strange; isn't a major > > > purpose of the kernel build procedure to minimize reliance on the > > > host system's (already-stale) software? > > > > Are you building in /usr/src, or are your sources located some place else? > > > This is a straightforward self-hosted build on an RPi3. Sources are in > /usr/src. There are no modifications to the source directories. > > > > > Really need the log that includes the cc command line, as that has the > > tell tell -I/usr/src/sys in it. That component is totally bogus! At > > no time should a src tree rooted at /usr/src-topo be trying to use files > > from /usr/src/. > > > Should files _outside_ /usr/src or /usr/obj _ever_ be referenced during > a world or kernel build? I thought the answer was "no". Well if your sources are at /usr/src, then rarely, but there are leaks that have happend where /usr/include is refenced. > The line leading up to the error message is: > I am going to split this line up at -I > --- armv8_crypto_wrap.o --- > cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch6 > 4/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -c -O3 -pipe -fno-strict-al > iasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /u > sr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC ^^^^^^^^^^^ Since your sources are /usr/src, this is fine, my problem is that I am compiling from /usr/src-topo, and I have patches, and these patches are NOT in /usr/src, but I have to put *some* of them in /usr/src to make my /usr/src-topo compile. SO something is broken, but I do not think that is what is effecting you. -I/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG - > ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan > t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar > ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kpri > ntf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -W > no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ > ality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-nega > tive-value -Wno-error-address-of-packed-member -std=iso9899:1999 -Werror -m > arch=armv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > > There's a "-I/usr/src/sys" in the fourth line, which in my case makes sense, > but where does the reference to /usr/lib/clang/.... come from, and is it > appropriate? Something for some reason included arm_neon.h? And I do not know why that was found at /usr/lib/clang/... Could it be something in that opt_global.h? Or something trigger by the -target arch, or the -m armv8? > > > If the two problems are related, should the subject line on the bug > > > report be changed? > > > > It could be, but more info would be needed. > > > Please let me know what additional information is needed. Your problem is not the same as mine. You are compiling from /usr/src, which hides the problem I am having. -- Rod Grimes rgrimes@freebsd.org