From owner-freebsd-ppc@freebsd.org Sun Dec 6 15:21:28 2015 Return-Path: Delivered-To: freebsd-ppc@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 401B699A10D for ; Sun, 6 Dec 2015 15:21:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 E08441F6D for ; Sun, 6 Dec 2015 15:21:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29908 invoked from network); 6 Dec 2015 15:21:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 15:21:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 10:21:22 -0500 (EST) Received: (qmail 19599 invoked from network); 6 Dec 2015 15:21:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 15:21:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F3501C43BF; Sun, 6 Dec 2015 07:21:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix Message-Id: Date: Sun, 6 Dec 2015 07:21:19 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 15:21:28 -0000 After successfully using the likes of: env MAKEOBJDIRPREFIX=3D. . . make . . . from the usual /usr/src starting point. I tried following: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are MAKEOBJDIRPREFIX, > WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are = environment-only > variables. by using env SRC_ENV_CONF=3D. . . make . . . and having the file pointed to contain the MAKEOBJDIRPREFIX=3D. . . . This did not work. Say MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain then I'd get errors for the = likes of /usr/obj/xtoolchain/legacy/usr/lib/ not existing during an install operation during buildworld. If I forced a such legacy directory tree to exist there by copying the = empty tree from /usr/obj/xtoolchain/usr/src/tmp/legacy/. . . (that it = had created) I continued to have problems elsewhere, such as: --- _libinstall --- sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libctf.a = /usr/obj/xtoolchain/usr/lib/ install: /usr/obj/xtoolchain/usr/lib/: No such file or directory *** [_libinstall] Error code 71 In essence the dynamic, local additions to the path such as usr/src/tmp/ = sometimes end up missing. My guess is that it is picking up the MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain definition again and so replacing the built-up prefix for the local = context. May be the quoted paragraph from "man src.conf" should not suggest that = MAKEOBJDIRPREFIX is valid in a file to be referenced by SRC_ENV_CONF: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are MAKEOBJDIRPREFIX, > WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are = environment-only > variables. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 6 16:33:00 2015 Return-Path: Delivered-To: freebsd-ppc@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 4D64D9A050F for ; Sun, 6 Dec 2015 16:33:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 036681BD1 for ; Sun, 6 Dec 2015 16:32:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2589 invoked from network); 6 Dec 2015 16:33:01 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:33:01 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 11:32:58 -0500 (EST) Received: (qmail 23724 invoked from network); 6 Dec 2015 16:32:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:32:58 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E51061C43BF; Sun, 6 Dec 2015 08:32:54 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure Message-Id: Date: Sun, 6 Dec 2015 08:32:57 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 16:33:00 -0000 Mostly just an FYI: This means that for my own purposes I'll tend to = avoid WITH_CCACHE_BUILD=3D for now. . . Context vintage: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 I took a working make command for buildworld and added > env CCACHE_DIR=3D/var/tmp/ccache and > WITH_CCACHE_BUILD=3D and then tried to repeat the build. The result was: > --- lib_gen.o --- > /usr/local/bin/ccache /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = -O2 -pipe -isystem /usr/obj/usr/src/tmp/usr/include/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/usr/lib/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/lib/. -L/usr/obj/usr/src/tmp/usr/lib/. = -L/usr/obj/usr/src/tmp/lib/. -I. = -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -MD -MP = -MF.depend.lib_gen.o -MTlib_gen.o -std=3Dgnu99 -fstack-protector-strong = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o lib_gen.o . . . > --- lib_gen.o --- > _67737.c:754:3: error: "_Bool" after # is not a positive integer > In file included from = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv.= h:313:0, > from lib_gen.c:19: > _67737.c:755:2: error: expected ')' before 'int' The make command was: > env CCACHE_DIR=3D/var/tmp/ccache make -j 6 \ > WITH_FAST_DEPEND=3D WITH_CCACHE_BUILD=3D \ > CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITH_LIBCPLUSPLUS=3D \ > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D \ > WITHOUT_CLANG_EXTRAS=3D \ > WITH_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 [Yes, I'm using powerpc64-xtoolchain-gcc/powerpc64-gcc on a powerpc64 = machine (PowerMac G5), no gcc 4.2.1 present and clang 3.7 unused for the = build: powerpc64-gcc is also in use as a system tool chain, not just as = the "self hosted" cross toolchain.] Removing > env CCACHE_DIR=3D/var/tmp/ccache and > WITH_CCACHE_BUILD=3D and then repeating went back to working again. I actually went back and = forth more than once and tested with and without WITH_FAST_DEPEND=3D as = I was experimenting with both. The reported behavior was uniform over = this activity. The ports vintage powerpc64-xtoolchain-gcc/powerpc64-gcc and other = things are from: > # svnlite info /usr/ports/ > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 402906 > Node Kind: directory > Schedule: normal > Last Changed Author: wen > Last Changed Rev: 402906 > Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 6 16:39:37 2015 Return-Path: Delivered-To: freebsd-ppc@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 8E60D9A05E8 for ; Sun, 6 Dec 2015 16:39:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 49F6D1CFC for ; Sun, 6 Dec 2015 16:39:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9820 invoked from network); 6 Dec 2015 16:39:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:39:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 11:39:38 -0500 (EST) Received: (qmail 13932 invoked from network); 6 Dec 2015 16:39:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:39:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C43BC1C43D5; Sun, 6 Dec 2015 08:39:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure From: Mark Millard In-Reply-To: Date: Sun, 6 Dec 2015 08:39:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24874B49-5D3A-4617-8DDA-B3F25E2419A4@dsl-only.net> References: To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 16:39:37 -0000 I'm adding a note about the missing "\" being just an E-mail editing = error, not an original command error. . . On 2015-Dec-6, at 8:32 AM, Mark Millard wrote: > Mostly just an FYI: This means that for my own purposes I'll tend to = avoid WITH_CCACHE_BUILD=3D for now. . . >=20 > Context vintage: >=20 >> # freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 >=20 > I took a working make command for buildworld and added >=20 >> env CCACHE_DIR=3D/var/tmp/ccache >=20 > and >=20 >> WITH_CCACHE_BUILD=3D >=20 > and then tried to repeat the build. The result was: >=20 >> --- lib_gen.o --- >> /usr/local/bin/ccache = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -O2 -pipe -isystem = /usr/obj/usr/src/tmp/usr/include/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/usr/lib/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/lib/. -L/usr/obj/usr/src/tmp/usr/lib/. = -L/usr/obj/usr/src/tmp/lib/. -I. = -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -MD -MP = -MF.depend.lib_gen.o -MTlib_gen.o -std=3Dgnu99 -fstack-protector-strong = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o lib_gen.o > . . . >> --- lib_gen.o --- >> _67737.c:754:3: error: "_Bool" after # is not a positive integer >> In file included from = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv.= h:313:0, >> from lib_gen.c:19: >> _67737.c:755:2: error: expected ')' before 'int' >=20 >=20 > The make command was: >=20 >> env CCACHE_DIR=3D/var/tmp/ccache make -j 6 \ >> WITH_FAST_DEPEND=3D WITH_CCACHE_BUILD=3D \ >> CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ >> WITH_LIBCPLUSPLUS=3D \ >> WITHOUT_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D \ >> WITHOUT_CLANG_EXTRAS=3D \ >> WITH_LLDB=3D \ >> WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ >> WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ >> buildworld buildkernel \ >> KERNCONF=3DGENERIC64vtsc-NODEBUG \ >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 >=20 Note: The missing \ after ". . . BOOTSTRAP=3D " is my mail-editing = error, not a problem with the original command. > [Yes, I'm using powerpc64-xtoolchain-gcc/powerpc64-gcc on a powerpc64 = machine (PowerMac G5), no gcc 4.2.1 present and clang 3.7 unused for the = build: powerpc64-gcc is also in use as a system tool chain, not just as = the "self hosted" cross toolchain.] >=20 > Removing >=20 >> env CCACHE_DIR=3D/var/tmp/ccache >=20 > and >=20 >> WITH_CCACHE_BUILD=3D >=20 > and then repeating went back to working again. I actually went back = and forth more than once and tested with and without WITH_FAST_DEPEND=3D = as I was experimenting with both. The reported behavior was uniform over = this activity. >=20 > The ports vintage powerpc64-xtoolchain-gcc/powerpc64-gcc and other = things are from: >=20 >> # svnlite info /usr/ports/ >> Path: /usr/ports >> Working Copy Root Path: /usr/ports >> URL: https://svn0.us-west.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 402906 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: wen >> Last Changed Rev: 402906 >> Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015) >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 6 21:34:40 2015 Return-Path: Delivered-To: freebsd-ppc@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 5678B9A0DAA for ; Sun, 6 Dec 2015 21:34:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 02B0F187E for ; Sun, 6 Dec 2015 21:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9791 invoked from network); 6 Dec 2015 21:34:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 21:34:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 16:34:39 -0500 (EST) Received: (qmail 7146 invoked from network); 6 Dec 2015 21:34:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 21:34:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EE6E01C43AE; Sun, 6 Dec 2015 13:34:32 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling Message-Id: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> Date: Sun, 6 Dec 2015 13:34:36 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 21:34:40 -0000 [I picked the lists that I did because powerpc64-gcc is the external = toolchain created to allow modern powerpc64 builds.] For the powerpc64-gcc 5.2 vintages. . . (using my environment's path as = an example) = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config= /rs6000/freebsd64.h has: > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 That type in quotes ends up being the base type for L". . ." notation, = for example. Probably the char notation as well (L'?'). For FreeBSD Char compatibility in a powerpc64 lib32 context that "long = int" should effectively instead be "int", making the conditional above = technically unnecessary. This blocks compiling lib32 source code that uses such notations as L". = . .": "long int" is not compatible with FreeBSD's Char in the powerpc64 = environment's 32 bit environment. Some compiler message are explicit = about the base types of pointers that result for the mismatches: that is = how I know that "long int" is in use for L". . ." and "int" is the other = base type involved. (Yes, freebsd64.h appears to be used for lib32, at least on powerpc64. = By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but only undef's = WCHAR_TYPE, presuming gcc defaults are correct for FreeBSD as far as the = type goes. It might need a more explicit type to be sure of a Char match = for that freebsd.h file's context.) The 4.9 vintages of powerpc64-gcc were messed up the same way, as was = noted at the time. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 6 22:44:16 2015 Return-Path: Delivered-To: freebsd-ppc@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 7C7D29A0C24; Sun, 6 Dec 2015 22:44:16 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (unknown [IPv6:2001:4060:1:1001::14:53]) (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 441F217AE; Sun, 6 Dec 2015 22:44:16 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPS id 79AA5CF0E8; Sun, 6 Dec 2015 23:44:02 +0100 (CET) Subject: Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling To: Mark Millard , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org References: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> From: Andreas Tobler Message-ID: <5664BA32.3010306@fgznet.ch> Date: Sun, 6 Dec 2015 23:44:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 127.0.1.1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 22:44:16 -0000 On 06.12.15 22:34, Mark Millard wrote: > [I picked the lists that I did because powerpc64-gcc is the external > toolchain created to allow modern powerpc64 builds.] > > For the powerpc64-gcc 5.2 vintages. . . (using my environment's path > as an example) > > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h > has: > >> /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults >> instead. */ #undef WCHAR_TYPE #define WCHAR_TYPE >> (TARGET_64BIT ? "int" : "long int") #undef WCHAR_TYPE_SIZE #define >> WCHAR_TYPE_SIZE 32 > > That type in quotes ends up being the base type for L". . ." > notation, for example. Probably the char notation as well (L'?'). > > For FreeBSD Char compatibility in a powerpc64 lib32 context that > "long int" should effectively instead be "int", making the > conditional above technically unnecessary. > > This blocks compiling lib32 source code that uses such notations as > L". . .": "long int" is not compatible with FreeBSD's Char in the > powerpc64 environment's 32 bit environment. Some compiler message are > explicit about the base types of pointers that result for the > mismatches: that is how I know that "long int" is in use for L". . ." > and "int" is the other base type involved. > > (Yes, freebsd64.h appears to be used for lib32, at least on > powerpc64. By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but > only undef's WCHAR_TYPE, presuming gcc defaults are correct for > FreeBSD as far as the type goes. It might need a more explicit type > to be sure of a Char match for that freebsd.h file's context.) > > The 4.9 vintages of powerpc64-gcc were messed up the same way, as was > noted at the time. I'll take care. Andreas From owner-freebsd-ppc@freebsd.org Mon Dec 7 20:49:07 2015 Return-Path: Delivered-To: freebsd-ppc@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 2DB629C1C69; Mon, 7 Dec 2015 20:49:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0132.outbound.protection.outlook.com [157.56.110.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 789671470; Mon, 7 Dec 2015 20:49:06 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0050.namprd05.prod.outlook.com (10.255.226.50) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 7 Dec 2015 20:48:58 +0000 Received: from BL2FFO11FD056.protection.gbl (2a01:111:f400:7c09::104) by BL2PR05CA0050.outlook.office365.com (2a01:111:e400:c04::50) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Mon, 7 Dec 2015 20:48:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD056.mail.protection.outlook.com (10.173.161.184) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Mon, 7 Dec 2015 20:48:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Dec 2015 12:48:56 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tB7KmuD62668; Mon, 7 Dec 2015 12:48:56 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id DA928580A9; Mon, 7 Dec 2015 12:48:55 -0800 (PST) To: Mark Millard CC: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix In-Reply-To: References: Comments: In-reply-to: Mark Millard message dated "Sun, 06 Dec 2015 07:21:19 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16607.1449521335.1@chaos> Date: Mon, 7 Dec 2015 12:48:55 -0800 Message-ID: <2426.1449521335@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD056; 1:HjEwlq3Hf8YvmAWgvsgmuN04IZLOmIt3w8aizVaaTB4eSsyEt2+utTmn0ZK6tjkQb5H3urbhAKK3u38ZDfGwX/DJ9b24/ZrwN4pfHURV7e5gXcsNkIeNAMgfNv2LHlOADpm9qR7oT/S5kf2PbHGDvHLdw0r/LZWIuzXblkATvy+HaSMXeSWRB7jB5Fjojbc24YHzoqrzR9i9QE5jY+VJ4Ed0GVTKzTME1NBdW68DS4R3G/ynmdpV8TgDOJn5PhM8b0ZMvRSAO/SBG94fQBDOOoGKYFeaZIL+M25OjM5O/4/4QiIve9fbbSgvEzjnCDVwE4RnOCYamUoDlTSF+ZRpF6C7o+jy/jIqSdikFDo/5S5WyQoqS6zQsx4UNWn1nz9R2gA8Tz9QFPFN5rohWjnX5Q== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(24454002)(69596002)(586003)(86362001)(6806005)(81156007)(57986006)(23726003)(11100500001)(33716001)(50226001)(76506005)(19580395003)(19580405001)(1096002)(105596002)(106466001)(5008740100001)(1220700001)(4001430100002)(110136002)(189998001)(76176999)(50986999)(50466002)(97736004)(5001960100002)(107886002)(47776003)(87936001)(46406003)(117636001)(77096005)(97756001)(2950100001)(92566002)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB053; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 2:Bre35UskhoEgBghVtCIJfTSeFPsyq6L2GiSTxOsA+THDK9ghdfbWfY8rVUxyroT7P2RM23aM3EphfgOJ3Ny0Z56jWCF+VQXNqEMcdgreZ6K8VE5MoKBzWn7IhjhNkVBikMmNreJwpzzGfmIkbzDwNQ==; 3:DbfiA4rQdaT0QX9BDm5bGFOItJSMD6Vx0vwTOT0mEolnANwKkQY0STdpyDzwpamcJVZfaFp4mY7kxA8afHXUOwe/pGEX2uUuyOXWwMWcrO1alPjn4J66I3hWLXqWpN40lpJpzhUn+51CM/mcqrI5G3ysU739c9AtnYZMlPCeaIsbUIjPwn7D3lzvpuG1NrDGszXYORj7n8T3BKbdKwoS+jtkBF4rE11r6/qBC2iUkLQ=; 25:EQNOxZh0J1Xw1nFNxRw02BvCpem+8mNiSyKkil2Xgg13x/qE5jwbYFHcMi6vRi+1ce1tGIqNv/gkZdqOGVBKhLZn9PDVf1jNDK5Wp5gsV+AiOvUCPyBOsynWh6KbxUggzcQ8vf+ZyOdMxV4swnjbOP6nDPLj48tq7U5Y+leO1M4OWtVh63GO+N/DKEjSfNJPdf3WYJgsESqlizVtEDmgMiAJ5gLUC/36BFY9EgcbD6QGl3glvi/5f+FRGBmmfmGq/JtMesY2LUr1uuZYnPlGDQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 20:VzYHxABT14qW/oPfMDVv79V1a1uo+x+oGKBP2NPOCuU1CgQfj70ABSAOwuimtFa3ysmAI+isJGlc83zIVfI3WuJgybADSr9csLF7hWMB+RoQ9vUOeLNIqVUHNg2iwl6p7B1zVfShGH79wW1Ya6BodIIbZMoqkSrJaJan7pzW7JyykgDLcSlmclWwsVNVgztq8AsiGMfiqbwPvxO8ArdjHG+w6PD0EupIljOR6UZyOgcYOTe4vwCOV9jZdFdeXydbQ/GGr03vA4mEpaXno+BtUwGBdQcStGiNftY7n7NdRIcdK/csJPNRpmefqwV7bVLRr2Du1oxiVElGUUxshwic2qwFzkqAvkh6atpAySThH62rsLcIl6LDMNfW3QEMZCkxEm0dMhdPCtByja93NAibEMto42IsbahjHgwXzETtevdGrCoL1GE8PMmsIi1GWb5jD8SxJQQ7pnVJ7SYt7A+YBioWFqHrPteRlpv3GxRrOgyLymdgQepd0m+stX57kfV9; 4:zLN7mkfhdTZjZAZWKB50qimi55+8kVmdBuy2weEW/aZG2/deg0gh/UdnKphx0OZ7dF+jmxcgDtdFiyZOJoFHd/lPqSO550dW8YRnvR9QNOc1Hm89YrkRZF0/KuV4DaYoDQHRy/O9FDmYoji1WPLQHgW9XrzULnd0vcr9WLMgrFfoG0WbiPhloHLDO9p4NiAGvorxTwRq+xw8u0gsZRZT2i6J0H8rwtvf/QPXI/NMc5mz/4ntoP8aESuF8TKv4xv8BcqFNDhktxpK0BQ7j16kHmhB6EQmLSLY6PPBXVDqcuPXBRKBFBEEbPy5V0xdgJ2BvNkCUFf+eFpyhIMg1acZtJguML5teihvmf0c5fRi2KpezAUEGMZzFtZZ1ld+XZVR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR05MB053; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB053; X-Forefront-PRVS: 078310077C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB053; 23:HZ73pB51Xv0nO1Op6i9ESeLr+v827xjZBnnrYwkjpH?= =?us-ascii?Q?PmpNmTn6RWJPL87rJcHXki2V8vA9ENSTCs6Ei+4ODRxzeDWGWQFXwYNN638U?= =?us-ascii?Q?nG0NMOZeervMqK5+dL7TvKfIMYGKeGB517g/3qqb1VXJ09CCgNokoMomX9JR?= =?us-ascii?Q?6KfFIPHrTIfTp5meT6CPl7w2HLjPu7xgUArGZXINFqdNRIqWnTd/NkJqwjpk?= =?us-ascii?Q?+NN5oexiPlQjTz97wffMKE6cmMVt5RkQu2R1MsgUZKUdn8MZR4OwZf/ctOTn?= =?us-ascii?Q?jeZ4mhJyuNfgOJAcbxskdkVQwR9uS59Rw9YY0iKfu8bS3m/oNzU4jI88n3jw?= =?us-ascii?Q?QuEOFTWJRQyOHDhGD6Aq7TqZT+RHb8acxARhq2oXwFVZFhF610PSfp4dYZPb?= =?us-ascii?Q?jqLAIoBV1+UjT3zBHYXCpBN7FhuhqVW/ZKqZ1jVLg1ZHxcMaFP46wNinxFsB?= =?us-ascii?Q?iQJ9TrhHEStJOTPrmTZDNlpfmrhrKL93X1k3Lx4yQFKKa6jRI0STOOhzyqpZ?= =?us-ascii?Q?5A8YWIvx8+Tff8qfUf9QEgIrLe+B0DwZbzjeQpK1y8fnQq9bWl+NEusJoDu0?= =?us-ascii?Q?uRrF2pPGwIY21+Jy/0QgCBBuN437soxOLSt/pVb+TlzjpSa9HCKnaCkBu+Pb?= =?us-ascii?Q?97+Y1AaJBCZp4Happux7CYowk0S51R48sLesNwBkOR4DOkB6rjUVkuUVj5/d?= =?us-ascii?Q?rm7oOOucHhpqA24ANWIaIjoI3WOQtZ/5ao0le2x7PvGrmz4qL2JdJvrYJLXi?= =?us-ascii?Q?QOjlQ1EPeumfuUcdBiN45r0tWBOMcQfSUrrjloa63+X+ZZgyOTefCLY3GOVT?= =?us-ascii?Q?U4JYZFuHIPBaXB4IPntLwS/GAOR55fURoSfuz4Vk6HTrfP43xAYbwDyi7/tU?= =?us-ascii?Q?elJF8r/Wk632POWsXD5SuN1OIwVkeFBfZwuxnSyRnvpBI+f4mRoc4SheRHeN?= =?us-ascii?Q?F16qFz1KWwlOm1PP3s3EB+TwZwTz1jH7HGHY349dJ6k3Pj5EIkQ78xB07bnJ?= =?us-ascii?Q?xOAjZ+QUWK+baPqvevYf1ldmHJa09Fhe3KAytAKt5l30dG/+WpuQ0zqtogin?= =?us-ascii?Q?fsgS7WOuHPBBbiCdcd9E0/y5bVkprw41IAKC5T70h8aQdzfOZIXzb2Y/TGHh?= =?us-ascii?Q?uEmnjTFKA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 5:CRpju4AnzHujn3WiOnIUkQYXqmBuhLGlFKHSg8yBJT/DzOTj7dCLgfB2Zypa4S8iLChDHaZ3zSqJin+w0F0TOj8VbrktRhS8EKHJPRsvYwXmz2AsTrI+kNagOgaKflagihAcAXqm5rWdhTh35iUjgA==; 24:HnfwEEhWX2gekZIg8WlOxpdg4fS6e1DmPPgUBaNg2h2mjgNxzNiYKP6l5nzUf3v5dcbdnmENwzgGqB5wBsTilpBieZkgcUvP8WFKRAlAW9Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2015 20:48:58.1220 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB053 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 20:49:07 -0000 Mark Millard wrote: > My guess is that it is picking up the > > MAKEOBJDIRPREFIX=/usr/obj/xtoolchain You should use ?= if you want this to work. There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked in the environment of a sub-make. By using = above, you break that. From owner-freebsd-ppc@freebsd.org Mon Dec 7 21:33:14 2015 Return-Path: Delivered-To: freebsd-ppc@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 F17DB9B7249 for ; Mon, 7 Dec 2015 21:33:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 A41A611B5 for ; Mon, 7 Dec 2015 21:33:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6803 invoked from network); 7 Dec 2015 21:33:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Dec 2015 21:33:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 07 Dec 2015 16:33:06 -0500 (EST) Received: (qmail 716 invoked from network); 7 Dec 2015 21:33:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 7 Dec 2015 21:33:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2EA0B1C43C4; Mon, 7 Dec 2015 13:33:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix From: Mark Millard In-Reply-To: <2426.1449521335@chaos> Date: Mon, 7 Dec 2015 13:33:05 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <2426.1449521335@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 21:33:15 -0000 > On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >=20 > Mark Millard wrote: >> My guess is that it is picking up the >>=20 >> MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain >=20 > You should use ?=3D if you want this to work. > There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is = tweaked > in the environment of a sub-make. >=20 > By using =3D above, you break that. That presumes that MAKEOBJDIRPREFIX has not been assigned a default = value before the SRC_ENV_CONF file has been included the first time. If = MAKEOBJDIRPREFIX had been defined already then the ?=3D would do nothing = and the wrong value would be used. I believe that the following trace shows that such an assignment of a = default value does happen first, making ?=3D not work either. /usr/src/Makefile (head/Makefile 29160) has > MAKEOBJDIRPREFIX?=3D /usr/obj at line 145 (used when it is not using targets/Makefile from the = relevant .if/.else/.endif). Line 105 has .include and there no others before the = above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), = which in turns includes bsd.mkopt.mk (only). That in turn includes = nothing else. So these files and only these files are the involved files = before that assignment as far as I can tell. None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not = happened yet when=20 > MAKEOBJDIRPREFIX?=3D /usr/obj is executed. So, if I understand right, MAKEOBJDIRPREFIX is already defined before = the code > SRC_ENV_CONF?=3D /etc/src-env.conf > .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) > .-include "${SRC_ENV_CONF}" > _src_env_conf_included_: .NOTMAIN > .endif is executed and so using ?=3D would not be effective in the included = file. Did I miss something? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Dec 7 22:33:39 2015 Return-Path: Delivered-To: freebsd-ppc@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 ABA419D3B32; Mon, 7 Dec 2015 22:33:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C188A1D96; Mon, 7 Dec 2015 22:33:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0030.namprd05.prod.outlook.com (10.255.226.30) by BY2PR05MB062.namprd05.prod.outlook.com (10.242.34.147) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 7 Dec 2015 22:19:11 +0000 Received: from BL2FFO11FD026.protection.gbl (2a01:111:f400:7c09::136) by BL2PR05CA0030.outlook.office365.com (2a01:111:e400:c04::30) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Mon, 7 Dec 2015 22:19:10 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Mon, 7 Dec 2015 22:19:10 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Dec 2015 14:15:47 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tB7MFjD38615; Mon, 7 Dec 2015 14:15:45 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 6D014580A9; Mon, 7 Dec 2015 14:15:45 -0800 (PST) To: Mark Millard CC: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix In-Reply-To: References: <2426.1449521335@chaos> Comments: In-reply-to: Mark Millard message dated "Mon, 07 Dec 2015 13:33:05 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22804.1449526545.1@chaos> Date: Mon, 7 Dec 2015 14:15:45 -0800 Message-ID: <2852.1449526545@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD026; 1:w4tRoobhgrEMUPWc3GhBrXtKDkc2CxaP8VskuHdmos/BNWzxSFn3JMSIIs6/z1mVMXp5eWRLALUI3AZUss3oIf6zyQ86y8yaDaCewJXvqhkI2KGZxNua7eYrMquMB08qR4Mv8kO8c+xHON8aqgg9rCn/kKh9XfTp3j62IvJ+KeP4EFSkirtbTNocfvW4Py5ghlBoMveqtdmbe9sYzp/V4glBbxRp5nRqD0TzKGRb1WLGfbNRyjytf4Ys7MH6Gh7ArNewa28VWzBgYx0bZx+axrp1crNccK/kqUHxgnBMhcSs1Kv30YDAYxMgBkwb7JuMZPHArKFO+PxHnqRc35/jmLMv9Vm4o8BqyL/V/hfKgyGMIabses/gmPpe4j4j24tfAw0kcpBXE+6ntug7149TWA== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(24454002)(5008740100001)(97736004)(81156007)(50986999)(1220700001)(97756001)(76176999)(46406003)(50226001)(4001430100002)(19580395003)(189998001)(19580405001)(69596002)(57986006)(76506005)(105596002)(1096002)(92566002)(586003)(87936001)(23726003)(11100500001)(86362001)(2950100001)(47776003)(5001960100002)(107886002)(77096005)(117636001)(50466002)(6806005)(33716001)(110136002)(106466001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB062; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 2:k/Nu/wzCtz6ii9eWRStFsYwljxT57TCIko5IWZChGZ5D67dJ+gc+usqtbFFw7FADC1DGH8Bc1HUofkkwmPp1EpLozrLqDeYSplwXHpmM3GNud6rCX7+GQcIJBKhFrIU/vxbAHKwgiJ1/wx/Orye/Pg==; 3:AfHU6ONU/uMStbrAZfdydGz7NAgg29LKyHZsTYIkq7lXw/Iyjv7sZgW61rcDFN3yNtODhReUruWlarkHP3BEdaJMktXSe26WBa/pt/HwyndGrY+dYl08+Sfrex9PmdVgkBjHq30yy4G5cGa8dqBNiQJa7vecEgGKD9uSWVB/EkiR77KPBniEW49XzCqsu/pU82wmIWxDVCBK3XflNeOHVhS9RGGJTQShyqoo1q9zrWQ=; 25:wT8z9YKfQxHvZusXCHI7I3N/cGQK20SThztL2HhASpHFnFlCZNhdMSVt9pUZugiAboyysouVzi3joiVBdQ5UfAPNFdL/aioUBQ0f9QJnRgi4lIppJiHh8blkSF0WpOcfWX+OOvHYUUVjDjDUYUhaGun92WOdNGl1gAFMI/l8Sri47Np7qO32Sh+EDWHeCGfx4u+W+qd+rRcjPrQd9YPjY0z+RWwbx+emFcIkmlOElYjbSUHPyepgB2Evz12NlVyfobNfnkxG/WUPU+VRdskw4w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB062; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 20:6qkhkl+f4+EDN5stQUaSIzuTIdHPa0pc/NV1AXA+CzQYFX4sDAHAwhw+A3LDWNfp5cLOTlmGrvIFHBQCTO67o5gSB4hlUr5CJbQyLqWqG7h6ejtrfYV+OA/4VYET3IAejMyU5HBDCWFYlBXys6QaIDLlbucyJzMe/g9nM64FzHmqUwvoCDksBRnwvvDXkYejBsHuUiDkcOaj1+Hbhg/UMTwYQ2jjsKZJ+X0fsp/Zqwlr0lwPowlGGmMdsufj4XLGNlTbWbfWdRBOGIVcg+1kJ0stojhdVtLKnF0bi0BRYfY2JHNobzFElSb7gWV6u3pqSplh0Fuxz4hUpKVZ4X8tnhQW450c4+ZcHjl5YkliU4hC4Q3MFQEHQHJW+QflQvClPkclOw5vgJkRfxuEPomq3PuHtKWv/e1jsbTIwSdmWQ6KD6cJx0FdTbQqHGwK0iYKiyeHklkfbWnezG7DaVK17wKHMCuCndWgJ7Eu/riDfbQmjaYXiIB5xLOOMwPgByeY; 4:S+G3ikOQ5QRDrgByqF4XnDe4/LIWwO4gjhwQk1dHC1366DxDciAk+Dp7jsWtn7h93OV//C1XnuUvM9b2i5CdydeZ4H+cY9+sxkYjCGBd4WuNVeo1F1CRJinPT/1qY1lJ//lQKQq6xDgCKLGwb5ouaVjAj3/O18WDdqmPGO6OO9kterDYD5tTSWX43IsA+pS0h76SqYUAiJCKZj1QKYRdBAus/ohgQifsZFzgiDte2LLl2hA6CP79yNceFmTpl4Jat07fRlJot30GakXBJdUwTKGVziSeMW1Gru9XjRx3HK7CW2KT31rpcwOiYEAxKGQeObuqiQVOWYd6jPo99/hejcJoFBczFv08Iteoo7xBNEESy2Kt1v7x3OgG4WBYoLUw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB062; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB062; X-Forefront-PRVS: 078310077C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB062; 23:z1fcTy2fI9dWS3Dm/jX2CflvOk5aUyHWDFhI+NtPhK?= =?us-ascii?Q?g+0RPrbqRmGsQcL3q7CGXpa5dkUvDm6Ec9qQvDxyUsC08bwHkBW07Ll5Ftnr?= =?us-ascii?Q?bJZt+j/sIwmoEZKlowOOvmmQRHjf831xxsKy7hgkGoiP+tQ7JbMQxsCDwy04?= =?us-ascii?Q?z7E5SFUR0s3tVFUd1L6c3OfB4hjvzdQhwXA/ezOMxQBLk1QQ/wSQ1Q5oruC0?= =?us-ascii?Q?Kudy7dwly7PakoTY2OR7o6x4hEVz7sCJ7lP1CxMan6WV3zKde0nP3DflgRLz?= =?us-ascii?Q?IeDnfUUd2o54/Gn+DqMVWuBt2WZij38m1fGS2dYvwZaMaUNaStZmbHAhOMAF?= =?us-ascii?Q?d8T63aKr0XlFrGA3tQFd2biLgRUxxPyaAi/Z6WT87z/w0/sgtmq/EqWreUWV?= =?us-ascii?Q?9Bkjev0GOCNgSAt2CM/kiHkzYwcZC03HMS6uw5ZR38Oxzt6c3vYuRQVQMh4t?= =?us-ascii?Q?9PoG2Iw7yHuHchMHkHTwDmWDVidod+KFmIoudF1H+OWHgCBsXzHc3j3/5gCb?= =?us-ascii?Q?CpO21Qvjuvw9WbP6SQs0AC/j2Gp4vonfPcgHgdWcRwzJxxInHq4XwZUBhg+7?= =?us-ascii?Q?O12tnESPG9oYqisS8I9lAX4FX53zTAZ62kKfmc1Kudf/We4jsfsavmh2ddJe?= =?us-ascii?Q?za+tXji+Hl/qzLEeEzpARI6c7GKnYXhYaKfL20uOHuSMLPnecdo1rH5k0K5v?= =?us-ascii?Q?8T/PMCxuXZMy0DPp4ADvzih3KazRkGc1szrlcK9MR+ejToU6avpenqiY14VP?= =?us-ascii?Q?rDIZnO/RRzOD1cTVdPWTCvAsPvrvXHUemSOuQ0n72kKLK7TUSO1abg0IQUla?= =?us-ascii?Q?tEPDqWHO/Xejm5hoGmzgZFvByu8PdMjK0lq/0CktsMCmZIh27Y/l5x4NyKFf?= =?us-ascii?Q?bZN1+L8w4pMpQePvpopIWC6H/K+luwjXRW29p5ay/JYG6MFQDepU6LLM+oFL?= =?us-ascii?Q?3wCvCzjdu44d6twZLqiLmYpwL4CKI/VVgxLDrofw4LPrlaSAMOobDO3ExrsV?= =?us-ascii?Q?+POjRwsmbfDmKW2HKzPoUBvsi9qW8Hao+ZqVOFDSFIrpH2jlLF2zxkIs6/G/?= =?us-ascii?Q?NEJxQ+GIVf99PkHZARUlHJZ+1r2oOKl1+9kBgjogdX3WrqLw0/hp2Rtm2i9O?= =?us-ascii?Q?oP8yeCOjc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 5:+++UgpfV3dFXdBOAQ0NXRIO8XXh1lAzPN73OIZ0VdIKxGWpfNkbQMA5oBgpvEdk5Q/Uzjx1uPSEtAbMu2fn90mLZMCZ77SEyKntH6fnnmz5ZeNEoB4ohzsh/1zhF13NEU2D3D2pgzwVgWUbIPxzmkg==; 24:wfbghy9nz1hQyNtvbsV5sthw5tjQxYAOeUEJBACNce20dY02Kpawr+BCb6y5iyp0H0T1QyiEkPdsfjefm8V1aawOtxpZa2clQBG2zvd1lfo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2015 22:19:10.3948 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB062 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 22:33:39 -0000 Mark Millard wrote: > >> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain > > > > You should use ?= if you want this to work. > > There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked > > in the environment of a sub-make. > > > > By using = above, you break that. > > That presumes that MAKEOBJDIRPREFIX has not been assigned a default > value before the SRC_ENV_CONF file has been included the first > time. Yes. If that's a concern: .if ${.MAKE.LEVEL} == 0 MAKEOBJDIRPREFIX= /usr/obj/xtoolchain .export MAKEOBJDIRPREFIX .endif will do what you want. From owner-freebsd-ppc@freebsd.org Tue Dec 8 22:14:22 2015 Return-Path: Delivered-To: freebsd-ppc@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 D53A79D452C; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C54BF1FC7; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id BD3FC1F8B; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7345B16D6D; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Uq7BxFo86i41; Tue, 8 Dec 2015 22:14:19 +0000 (UTC) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 431EC16D64 To: Mark Millard , "Simon J. Gerraty" References: <2426.1449521335@chaos> Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current From: Bryan Drewery Organization: FreeBSD Message-ID: <56675638.5010904@FreeBSD.org> Date: Tue, 8 Dec 2015 14:14:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:14:22 -0000 On 12/7/15 1:33 PM, Mark Millard wrote: > >> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >> >> Mark Millard wrote: >>> My guess is that it is picking up the >>> >>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain >> >> You should use ?= if you want this to work. >> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked >> in the environment of a sub-make. >> >> By using = above, you break that. > > That presumes that MAKEOBJDIRPREFIX has not been assigned a default value before the SRC_ENV_CONF file has been included the first time. If MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and the wrong value would be used. > > I believe that the following trace shows that such an assignment of a default value does happen first, making ?= not work either. > > > > /usr/src/Makefile (head/Makefile 29160) has > >> MAKEOBJDIRPREFIX?= /usr/obj > > at line 145 (used when it is not using targets/Makefile from the relevant .if/.else/.endif). > > Line 105 has .include and there no others before the above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So these files and only these files are the involved files before that assignment as far as I can tell. > > None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened yet when > >> MAKEOBJDIRPREFIX?= /usr/obj > > is executed. > > So, if I understand right, MAKEOBJDIRPREFIX is already defined before the code > >> SRC_ENV_CONF?= /etc/src-env.conf >> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) >> .-include "${SRC_ENV_CONF}" >> _src_env_conf_included_: .NOTMAIN >> .endif > > is executed and so using ?= would not be effective in the included file. > > Did I miss something? Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it as being in line 0. Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or src.conf if you are not using any of the meta mode features (all off by default). -- Regards, Bryan Drewery From owner-freebsd-ppc@freebsd.org Wed Dec 9 14:04:19 2015 Return-Path: Delivered-To: freebsd-ppc@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 AE6199D52F5 for ; Wed, 9 Dec 2015 14:04:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 5B2AD105A for ; Wed, 9 Dec 2015 14:04:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15716 invoked from network); 9 Dec 2015 14:04:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Dec 2015 14:04:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 09 Dec 2015 09:04:15 -0500 (EST) Received: (qmail 23234 invoked from network); 9 Dec 2015 14:04:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 9 Dec 2015 14:04:14 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7C5301C43BA; Wed, 9 Dec 2015 06:04:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling From: Mark Millard In-Reply-To: <5664BA32.3010306@fgznet.ch> Date: Wed, 9 Dec 2015 06:04:10 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org, Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <1D7927B2-9CC4-4F43-A6A5-2F2B855CDAE9@dsl-only.net> References: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> <5664BA32.3010306@fgznet.ch> To: Andreas Tobler X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:04:19 -0000 [This time I'm explicit about a patch-gcc-freebsd-powerpc64 update and I = report that with the change the PowerMac G5 hosted powerpc64-gcc based = buildworld attempt completed, including WITH_LIB32=3D and WITH_BOOT=3D = being involved. (But it may not be until tomorrow or later until I test = if such a build actually works for installworld and reboot.)] > On 2015-Dec-6, at 2:44 PM, Andreas Tobler = wrote: >=20 > On 06.12.15 22:34, Mark Millard wrote: >> [I picked the lists that I did because powerpc64-gcc is the external >> toolchain created to allow modern powerpc64 builds.] >>=20 >> For the powerpc64-gcc 5.2 vintages. . . (using my environment's path >> as an example) >>=20 >> = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config= /rs6000/freebsd64.h >> has: >>=20 >>> /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults >>> instead. */ #undef WCHAR_TYPE #define WCHAR_TYPE >>> (TARGET_64BIT ? "int" : "long int") #undef WCHAR_TYPE_SIZE #define >>> WCHAR_TYPE_SIZE 32 >>=20 >> That type in quotes ends up being the base type for L". . ." >> notation, for example. Probably the char notation as well (L'?'). >>=20 >> For FreeBSD Char compatibility in a powerpc64 lib32 context that >> "long int" should effectively instead be "int", making the >> conditional above technically unnecessary. >>=20 >> This blocks compiling lib32 source code that uses such notations as >> L". . .": "long int" is not compatible with FreeBSD's Char in the >> powerpc64 environment's 32 bit environment. Some compiler message are >> explicit about the base types of pointers that result for the >> mismatches: that is how I know that "long int" is in use for L". . ." >> and "int" is the other base type involved. >>=20 >> (Yes, freebsd64.h appears to be used for lib32, at least on >> powerpc64. By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but >> only undef's WCHAR_TYPE, presuming gcc defaults are correct for >> FreeBSD as far as the type goes. It might need a more explicit type >> to be sure of a Char match for that freebsd.h file's context.) >>=20 >> The 4.9 vintages of powerpc64-gcc were messed up the same way, as was >> noted at the time. >=20 > I'll take care. >=20 > Andreas (I make no claim that this note manages to preserve tabs and such in the = diff -u text.) To turn my earlier note into an actual updated = devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 instead of the = more vague words would involve adding what would look something like: > @@ -304,7 +317,7 @@ > =20 > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > -#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > +#define WCHAR_TYPE "int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 >=20 (It is what I actually tested.) The full patch-gcc-freebsd-powerpc64 would then look something like: > --- gcc/config/rs6000/freebsd64.h.orig 2015-01-05 04:33:28.000000000 = -0800 > +++ gcc/config/rs6000/freebsd64.h 2015-12-09 00:14:28.520684000 = -0800 > @@ -65,6 +65,13 @@ > #define INVALID_64BIT "-m%s not supported in this configuration" > #define INVALID_32BIT INVALID_64BIT > =20 > +/* Use LINUX64 instead of FREEBSD64 for compat with e.g. sysv4le.h */ > +#ifdef LINUX64_DEFAULT_ABI_ELFv2 > +#define ELFv2_ABI_CHECK (rs6000_elf_abi !=3D 1) > +#else > +#define ELFv2_ABI_CHECK (rs6000_elf_abi =3D=3D 2) > +#endif > + > #undef SUBSUBTARGET_OVERRIDE_OPTIONS > #define SUBSUBTARGET_OVERRIDE_OPTIONS \ > do \ > @@ -84,6 +91,12 @@ > rs6000_isa_flags &=3D ~OPTION_MASK_RELOCATABLE; \ > error (INVALID_64BIT, "relocatable"); \ > } \ > + if (ELFv2_ABI_CHECK) \ > + { \ > + rs6000_current_abi =3D ABI_ELFv2; \ > + if (dot_symbols) \ > + error ("-mcall-aixdesc incompatible with = -mabi=3Delfv2"); \ > + } \ > if (rs6000_isa_flags & OPTION_MASK_EABI) \ > { \ > rs6000_isa_flags &=3D ~OPTION_MASK_EABI; \ > @@ -304,7 +317,7 @@ > =20 > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > -#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > +#define WCHAR_TYPE "int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > =20 I can report that a make buildworld with the following WITH/WITHOUT = src.conf type options competed based on the rebuilt powerpc64-gcc. = (WITHOUT_CLANG=3D and WITHOUT_LLDB=3D were just to save time. The = context is already libc++ based and so WITHOUT_GCC=3D and = WITHOUT_GNUXX=3D.) > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc > TARGET_ARCH=3Dpowerpc64 > WITHOUT_CROSS_COMPILER=3D > # > # 1 thing that fails to build if attempted: > WITHOUT_CLANG_EXTRAS=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BOOT=3D > WITH_LIB32=3D > WITHOUT_CLANG=3D > WITHOUT_CLANG_IS_CC=3D > WITHOUT_CLANG_FULL=3D > WITHOUT_LLDB=3D > # > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > #CFLAGS+=3D -DELF_VERBOSE > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D The FreeBSD version context is: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 The technique of using powerpc64-gcc as the host/cross compiler in this = context was as follows. (No gcc 4.2.1 present and clang 3.7 unused. No = initial lib32.) First some symbolic links: > # ls -al /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Dec 5 05:41 /usr/lib/libstdc++.a -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Dec 5 05:41 /usr/lib/libstdc++.so -> = libc++.so > # ls -l /usr/bin/g[c+][c+] > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/g++ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc These cover the existing forced, explicit "gcc" commands in a powerpc64 = related csu Makefile and other "old style" references that occur. Also some other file updates: > # svnlite diff /usr/src/ > Index: /usr/src/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/ofw/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" There is more src.conf type content to cause use of the powerpc64-gcc = toolchain: > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > # > DEPFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/c+= +/v1/. -I/usr/include/c++/v1/. > # > CFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. > # > LDFLAGS+=3D -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. > # > CXXFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/c+= +/v1/. -std=3Dgnu++11 > # > CXXFLAGS+=3D -I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (I'll not get into the details of my workaround for building = powerpc64-gcc in a powerpc64 context, where it is not truly a cross = compiler. I copy 6 files to the right staging place/name when they are = not found and then restart the powerpc64-gcc install. I use gcc49 to = build powerpc64-gcc.) From owner-freebsd-ppc@freebsd.org Thu Dec 10 19:57:04 2015 Return-Path: Delivered-To: freebsd-ppc@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 2A78A9D64A7 for ; Thu, 10 Dec 2015 19:57:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 B91AE1FF4 for ; Thu, 10 Dec 2015 19:57:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26366 invoked from network); 10 Dec 2015 19:56:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Dec 2015 19:56:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Thu, 10 Dec 2015 14:56:56 -0500 (EST) Received: (qmail 6995 invoked from network); 10 Dec 2015 19:56:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 10 Dec 2015 19:56:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5D78C1C43C1; Thu, 10 Dec 2015 11:56:52 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: bug 205183: powerpc64's 11.0-CURRENT clang 3.7 crashes compiling atf-check.cpp during buildworld Message-Id: <69FFE249-A5B2-4D2E-B05B-7875F7572459@dsl-only.net> Date: Thu, 10 Dec 2015 11:56:55 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Thu, 10 Dec 2015 21:47:49 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 19:57:04 -0000 I have submitted bug 205183 for powerpc64's 11.0-CURRENT r291745 system = clang 3.7 crashing when compiling contrib/atf/atf-sh/atf-check.cpp = during buildworld. The backtrace and a .zip of the atf-check-a96a93.cpp = and atf-check-a96a93.sh provided were submitted. The "Affects Only Me" status might need to change if others also see the = crash. In my context it is reproducible. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Dec 10 22:27:33 2015 Return-Path: Delivered-To: freebsd-ppc@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 29EC09D6036; Thu, 10 Dec 2015 22:27:33 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id E4C111BE6; Thu, 10 Dec 2015 22:27:32 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id B0FB81E209B4; Thu, 10 Dec 2015 23:19:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1449785970; bh=n4IKAKhbCC29mxRTfKzqk58bM/b7+Q4cwiU/xKYwPnE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Z7xKvicCEslCXMYDcJHvvnjihUWIffcN4tnkTUytbTU/9lg86xVyQ+ob4gfmXlntN GFB4+8FLNcOPHw1K29td3iElWL+gFK3hcLEhy9mb6F6O3AmYgqQN6UWlgvlfL3LyTf yeQVubK5flg9ZxiBqVcZmm5jyT0Qv+se08dLqDxM= Date: Thu, 10 Dec 2015 23:19:30 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Subject: Re: bug 205183: powerpc64's 11.0-CURRENT clang 3.7 crashes compiling atf-check.cpp during buildworld Message-ID: <20151210221930.GA52091@vlakno.cz> References: <69FFE249-A5B2-4D2E-B05B-7875F7572459@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69FFE249-A5B2-4D2E-B05B-7875F7572459@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 22:27:33 -0000 On Thu, Dec 10, 2015 at 11:56:55AM -0800, Mark Millard wrote: > I have submitted bug 205183 for powerpc64's 11.0-CURRENT r291745 system clang 3.7 crashing when compiling contrib/atf/atf-sh/atf-check.cpp during buildworld. The backtrace and a .zip of the atf-check-a96a93.cpp and atf-check-a96a93.sh provided were submitted. > > The "Affects Only Me" status might need to change if others also see the crash. In my context it is reproducible. > This is https://llvm.org/bugs/show_bug.cgi?id=25802 From owner-freebsd-ppc@freebsd.org Fri Dec 11 06:37:23 2015 Return-Path: Delivered-To: freebsd-ppc@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 982609D53B9 for ; Fri, 11 Dec 2015 06:37:23 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) Received: from mailer233.gate85.rs.smtp.com (mailer233.gate85.rs.smtp.com [74.91.85.233]) (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 4D3A01E5A for ; Fri, 11 Dec 2015 06:37:22 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) X-MSFBL: eyJyIjoiZnJlZWJzZC1wcGNAZnJlZWJzZC5vcmciLCJiIjoiNzRfOTFfODVfMjMz IiwiZyI6IlNuc3RlbGVjb21fZGVkaWNhdGVkX3Bvb2wifQ== Received: from [192.168.80.41] ([192.168.80.41:33435] helo=rs-ord-mta04-1.smtp.com) by rs-ord-mta04-3.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTP id 46/81-28065-12F6A665; Fri, 11 Dec 2015 06:37:21 +0000 X-MSFBL: eyJnIjoiU25zdGVsZWNvbV9kZWRpY2F0ZWRfcG9vbCIsInIiOiJmcmVlYnNkLXBw Y0BmcmVlYnNkLm9yZyIsImIiOiJTbnN0ZWxlY29tX2RlZGljYXRlZF9wb29sIn0= DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1449815841; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=0WK8NqB4/eQKKd5/oJb6Aqq2b12zsvIMSVnKJ/O4ayw=; b=HDT5k5LKwywtGLo8f11Z0Su6p41RjJ6ofRhjH+0fmzbqu4pfe0vRq0kWzk5dZP8F CLeglQif1qEYGGYAT6Z48kYrLAi19YONgPp2uwO2aCoqGnasnVnxKLFNgOujWUD3 fu2XP5plr5SGCIpk1dk/IyrunTWTD0xSGhWV3eiH61w=; Received: from [154.20.125.37] ([154.20.125.37:36986] helo=d154-20-125-37.bchsia.telus.net) by rs-ord-mta04-1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id C3/36-32659-12F6A665; Fri, 11 Dec 2015 06:37:21 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snscommunication.com To: freebsd-ppc@freebsd.org Subject: The M2M & IoT Ecosystem: 2015 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Thu, 10 Dec 2015 22:37:13 -0800 Message-ID: <79764371672641271019592@Ankur> X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Tracking-Number: 7d919278-2594-4335-ab30-d71109216de5 X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 06:37:23 -0000 The LPWA (Low Power Wide Area) Networks Ecosystem: 2015 =96 2030 =96 Opport= unities, Challenges, Strategies, Industry Verticals & Forecasts Hello=20 Hope you are doing well.=20 I wanted to bring to your attention the latest SNS Research report in which= you might be interested, " The LPWA (Low Power Wide Area) Networks Ecosyst= em: 2015 =96 2030 =96 Opportunities, Challenges, Strategies, Industry Verti= cals & Forecasts."=20 I believe this report will be highly applicable for you. If you would like = to see the report sample or have any questions, please let me know. =20 Report Information: Release Date: November 2015 Number of Pages: 192 Number of Tables and Figures: 51 Report Overview: Until recently, most M2M and IoT services have largely relied on licensed c= ellular, wireline and satellite networks for their wide area connectivity r= equirements. Cellular networks, in particular, have enjoyed significant suc= cess in the arena. However, for many low bandwidth IoT applications, tradit= ional cellular networks are deemed too expensive due excessive power consum= ption and complex protocols that lower battery life. As a result, a number = of LPWA (Low Power Wide Area) alternatives have emerged that specifically s= eek to address these concerns. LPWA networks are optimized to provide wide area coverage with minimal powe= r consumption. Typically reliant on unlicensed frequencies, LPWA devices ha= ve low data rates, long battery lives and can operate unattended for long p= eriods of time. Already prevalent in IoT applications such as smart metering, lighting cont= rol and parking management, LPWA networks are expected to make a significan= t contribution to the M2M and IoT ecosystem, with an estimated $27 Billion = in service revenue by 2020. The =93LPWA (Low Power Wide Area) Networks Ecosystem: 2015 =96 2030 =96 Opp= ortunities, Challenges, Strategies, Industry Verticals & Forecasts=94 repor= t presents an in-depth assessment of the LPWA networks ecosystem including = LPWA technologies, key trends, market drivers, challenges, vertical market = applications, deployment case studies, regulatory landscape, standardizatio= n, opportunities, future roadmap, value chain, ecosystem player profiles an= d strategies. The report also presents market size forecasts from 2015 till= 2030. The forecasts are segmented for 9 vertical markets and 6 regions. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report. =20 Key Findings: The report has the following key findings: Already prevalent in IoT applications such as smart metering, lighting cont= rol and parking management, LPWA networks are expected to make a significan= t contribution to the M2M and IoT ecosystem, with an estimated $27 Billion = in service revenue by 2020. As of Q4=922015, SNS Research estimates the cost of a typical LPWA module t= o be $5-20, depending on the specific technology. As LPWA network deploymen= ts mature, we expect that the cost per module can drop down to as low as $1= -2 in volume quantities. At present, a majority of LPWA networks operate in license-exempt spectrum = primarily in sub-GHz bands. There are a number of ongoing initiatives that = call for regulators to dedicate spectrum bands exclusively for LPWA network= s as mass market adoption of unlicensed LPWA networks can result in signifi= cant interference. Besides optimizing their cellular networks for M2M services, mobile operato= rs are increasingly investing in their own carrier-grade LPWA networks to s= upport low bandwidth IoT applications. Topics Covered: The report covers the following topics: LPWA networks ecosystem Market drivers and barriers LPWA technologies, spectrum bands and key trends Assessment of competing cellular, satellite, wireline and short range netwo= rking technologies Vertical market applications, opportunities and deployment case studies Regulatory landscape and standardization Industry roadmap and value chain Profiles and strategies of over 80 leading ecosystem players Strategic recommendations for ecosystem players Market analysis and forecasts from 2015 till 2030 Historical Revenue & Forecast Segmentation: Connection and service revenue forecasts are provided for the following sub= markets: Vertical Markets Agriculture Asset Management & Logistics Automotive & Transportation Consumer Applications & Home Automation Energy & Utilities Healthcare Intelligent Buildings & Infrastructure Public Safety, Security & Surveillance Retail & Vending Others Regional Markets Asia Pacific Eastern Europe Middle East & Africa Latin & Central America North America Western Europe Key Questions Answered: The report provides answers to the following key questions: How big is the LPWA networks opportunity=3F What trends, challenges and barriers are influencing its growth=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F Which regions and submarkets will see the highest percentage of growth=3F How are smart city initiatives driving LPWA network investments=3F What are the key performance characteristics of LPWA technologies such as S= igfox, LoRa and NB-IOT=3F How does regulation impact the adoption of LPWA networks=3F Do LPWA networks pose a threat to cellular network technologies=3F Who are the key market players and what are their strategies=3F What strategies should LPWA technology providers, mobile operators, MVNOs, = aggregators, IoT platform providers and other ecosystem players adopt to re= main competitive=3F Report Pricing: Single User License: USD 2,500 Company Wide License: USD 3,500 Ordering Process: Please contact Andy Silva on andy.silva@snscommunication.com Provide the following information: 1. Report Title - 2. Report License - (Single User/Company Wide) 3. Name - 4. Email - 5. Job Title - 6. Company - 7. Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned below for your better inside. I look forward to hearing from you. Kind Regards Andy Silva Marketing Executive Signals and Systems Telecom Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 ___________________________________________________________________________= __________________________________________________________________________ =20 Table of Content =20 1.1 Executive Summary 1.2 Topics Covered 1.3 Historical Revenue & Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 Chapter 2: An Overview of LPWA Networks 2.1 M2M Networks & the IoT Vision 2.1.1 What is M2M Technology=3F 2.1.2 The IoT Vision 2.1.3 M2M & IoT Architecture 2.2 The Limitations of Traditional M2M Networking Technologies 2.3 What are LPWA Networks=3F 2.4 Key Characteristics of LPWA Networks 2.4.1 Long Range & Strong Propagation 2.4.2 Star Network Topology 2.4.3 Low Data Rates 2.4.4 Low Power Consumption 2.4.5 Battery Life Requirements 2.4.6 Scalability 2.4.7 Low Cost Modules & Infrastructure 2.4.8 Supplementary Features 2.5 Market Growth Drivers 2.5.1 Addressing Low Throughput IoT Use Cases 2.5.2 Cost Saving Potential 2.5.3 Energy Saving: Towards Green IoT Networks 2.5.4 The 2G Sunset 2.5.5 Regulatory Initiatives & Mandates 2.5.6 Interest from Vertical Markets 2.5.7 Commitments by Industry Giants 2.6 Market Barriers 2.6.1 Lack of Standardization 2.6.2 Interference Concerns 2.6.3 Low Revenue per Connection 2.6.4 Integration Complexities =20 Chapter 3: LPWA Networking Technologies 3.1 UNB (Ultra Narrow Band) 3.1.1 Sigfox 3.1.2 Telensa 3.2 LoRa Alliance 3.2.1 Semtech=92s LoRA RF Platform 3.2.2 LoRaWAN 3.2.3 Link Labs=92 Symphony Link 3.3 Weightless SIG 3.3.1 Weightless-W 3.3.2 Weightless-N 3.3.3 Weightless-P 3.4 Ingenu=92s RPMA (Random Phase Multiple Access) 3.5 3GPP Technologies 3.5.1 NB-IOT (Narrow Band IOT) 3.5.2 Clean-Slate Approach: New Air Interface 3.5.3 NB-LTE (Narrow Band LTE) 3.5.4 EC-GSM (Extended Coverage GSM) 3.6 IEEE 802.11 ah & af 3.7 Spectrum Options for LPWA Networks 3.7.1 ISM (Industrial, Scientific, and Medical Radio) Bands 3.7.2 TVWS (TV White Spaces) 3.7.3 Licensed Spectrum 3.8 Competing M2M Networking Technologies 3.8.1 Traditional Cellular Networks 3.8.1.1 2G & 3G 3.8.1.2 LTE 3.8.1.3 5G 3.8.2 Satellite Communications 3.8.3 Wireline Networks 3.8.4 Short Range Networks 3.8.4.1 WiFi 3.8.4.2 Bluetooth 3.8.4.3 ZigBee 3.8.5 Others =20 Chapter 4: Vertical Market Applications, Opportunities & Case Studies 4.1 Agriculture 4.1.1 Precision Agriculture 4.1.2 Livestock Management 4.1.3 Agricultural Equipment Monitoring 4.2 Asset Management & Logistics 4.2.1 Maintaining Real-Time Asset Inventories 4.2.2 Supply Chain Visibility 4.2.3 Tracking Containers & Goods 4.2.4 Monitoring of Shipment Conditions 4.2.5 Other Applications 4.3 Automotive & Transportation 4.3.1 Tracking & Location Services 4.3.2 Remote Vehicle Management 4.3.3 Safety & Security 4.3.4 Other Applications 4.4 Consumer Applications & Home Automation 4.4.1 Wide Area Tracking 4.4.2 Sports & Fitness 4.4.3 Smart Homes & Intelligent Appliances 4.5 Energy & Utilities 4.5.1 Smart Metering 4.5.2 Applications in the Oil & Gas Sector 4.6 Healthcare 4.6.1 Health & Wellness Monitoring 4.6.2 Diagnostic Tools 4.6.3 Connected Prescription Reminders 4.6.4 Other Applications 4.7 Intelligent Buildings & Infrastructure 4.7.1 Intelligent Buildings 4.7.2 Public Infrastructure Management 4.7.3 Parking Management 4.7.4 Lighting Control 4.7.5 Waste Management 4.7.6 Environmental Monitoring & Other Applications 4.8 Public Safety, Security & Surveillance 4.8.1 Perimeter Access Control 4.8.2 Connected Security Alarms 4.8.3 Other Applications 4.9 Retail & Vending 4.9.1 POS (Point of Sale) Applications 4.9.2 Intelligent Shopping 4.9.3 Smart Restocking 4.9.4 Other Applications 4.10 Other Verticals 4.11 LPWA Deployment Case Studies 4.11.1 BT: Creating the UK=92s First IoT Enabled Smart City 4.11.2 Du: Supporting Smart City Initiatives with LPWA Networking 4.11.3 Enevo: Waste Logistics Optimization 4.11.4 Securitas: LPWA Powered Home Security Monitoring 4.11.5 Senet: Optimizing Fuel Delivery with LPWA Networking 4.11.6 Smarteo Water: Enabling Smart Metering with LPWA Networking 4.11.7 Telensa: Smart Parking & Street Lighting 4.11.8 The Things Network: Crowdsouring IoT Networks =20 Chapter 5: Regulatory Landscape 5.1 3GPP (3rd Generation Partnership Project) 5.2 LoRa Alliance 5.3 Weightless SIG 5.4 IEEE (Institute of Electrical and Electronics Engineers) 5.5 Wireless IoT Forum 5.6 GSMA =20 Chapter 6: Industry Roadmap & Value Chain 6.1 Industry Roadmap 6.1.1 2015 =96 2020: Initial Rollouts to Support Smart City Applications 6.1.2 2020 =96 2025: Moving Towards Licensed Spectrum & Technologies 6.1.3 2025 =96 2030 & Beyond: Cannibalizing Legacy Cellular M2M Connectio= ns 6.2 Value Chain 6.2.1 Enabling Technology 6.2.1.1 Hardware Providers 6.2.1.2 Software Providers 6.2.2 Connectivity 6.2.2.1 Mobile Operators 6.2.2.2 MVNOs & Aggregators 6.2.3 Service Enablement 6.2.3.1 CDP (Connected Device Platform) Providers 6.2.3.2 Application Platform Providers 6.2.4 Vertical Solutions 6.2.4.1 System Integrators 6.2.4.2 Vertical Market Specialists 6.2.5 Other Ecosystem Players 6.2.5.1 Cloud Platform Providers 6.2.5.2 Big Data & Analytics Specialists 6.2.5.3 Supplementary Service Providers =20 Chapter 7: Key Market Players 7.1 Accellus Communication Networks 7.2 Actility 7.3 Adeunis RF 7.4 Aerea 7.5 AMBER Wireless 7.6 Arkessa 7.7 Arqiva 7.8 AT&T 7.9 Atim 7.10 Atmel Corporation 7.11 Augtek 7.12 AXSEM 7.13 Bouygues Telecom 7.14 BT Group 7.15 Cellnex Telecom (Abertis Telecom) 7.16 CG-Wireless 7.17 Cisco Systems 7.18 Digi International 7.19 DT (Deutsche Telekom) 7.20 Du (Emirates Integrated Telecommunications Company) 7.21 Elster Group 7.22 Eolane 7.23 Ericsson 7.24 Etisalat Group 7.25 Eutelsat 7.26 FLASHNET 7.27 Helium Systems 7.28 Homerider Systems 7.29 Hope RF (Hope Microelectronics) 7.30 Huawei 7.31 IBM 7.32 IMST 7.33 Ingenu 7.34 Intel Corporation 7.35 Kerlink 7.36 KPN 7.37 Libelium 7.38 Link Labs 7.39 M2COMM (M=B2Communication) 7.40 M2M Spectrum Networks 7.41 Microchip Technology 7.42 Multi-Tech Systems 7.43 Nemeus 7.44 Nettrotter 7.45 NNNCo (National Narrowband Network Communications) 7.46 Nokia 7.47 NTT DoCoMo 7.48 Nwave Technologies 7.49 Orange 7.50 OrbiWise 7.51 PicoWAN 7.52 Plextek 7.53 Proximus Group 7.54 Qowiso 7.55 Qualcomm 7.56 Radiocrafts 7.57 Sagemcom 7.58 Samsara Networks 7.59 Samsung Electronics 7.60 Semtech Corporation 7.61 Senet 7.62 Sierra Wireless 7.63 Sigfox 7.64 Silicon Labs (Silicon Laboratories) 7.65 SimpleCell Networks 7.66 Singtel 7.67 SK Telecom 7.68 Stream Technologies 7.69 Swisscom 7.70 Tata Communications 7.71 Tele2 7.72 Telecom Design 7.73 Telecom Italia 7.74 Telef=F3nica 7.75 Telensa 7.76 Telit Communications 7.77 Telkom SA 7.78 Telstra Corporation 7.79 The Things Network 7.80 TI (Texas Instruments) 7.81 U-blox 7.82 Vodafone Group 7.83 WAVIoT =20 Chapter 8: Market Analysis & Forecasts 8.1 Global Outlook of LPWA Networks 8.1.1 LPWA Network Connections 8.1.2 LPWA Network IoT Service Revenue 8.2 Connectivity vs. Application Services 8.2.1 Connectivity Revenue 8.2.2 IoT Application Service Revenue 8.3 Vertical Market Segmentation 8.3.1 Agriculture 8.3.2 Asset Management & Logistics 8.3.3 Automotive & Transportation 8.3.4 Consumer Applications & Home Automation 8.3.5 Energy & Utilities 8.3.6 Healthcare 8.3.7 Intelligent Buildings & Infrastructure 8.3.8 Public Safety, Security & Surveillance 8.3.9 Retail & Vending 8.3.10 Others 8.4 Regional Segmentation 8.4.1 Asia Pacific 8.4.2 Eastern Europe 8.4.3 Middle East & Africa 8.4.4 Latin & Central America 8.4.5 North America 8.4.6 Western Europe =20 Chapter 9: Conclusion & Strategic Recommendations 9.1 Why is the Market Poised to Grow=3F 9.2 Competitive Industry Landscape: Acquisitions, Alliances & Consolidation 9.3 Prospects of Licensed Spectrum for LPWA Networks 9.4 SWOT Analysis: LPWA vs. Competing Technologies 9.5 Geographic Outlook: Which Regions Offer the Highest Growth Potential=3F 9.6 Reducing LPWA Module Costs 9.7 Smart City Infrastructure Projects: Driving LPWA Network Rollouts 9.8 Impact on Mobile Operators: Opportunities & Challenges 9.9 Strategic Recommendations 9.9.1 LPWA Technology Providers 9.9.2 Other Enabling Technology Providers 9.9.3 Mobile Operators 9.9.4 MVNOs & Aggregators 9.9.5 IoT Platform Providers 9.9.6 System Integrators & Vertical Market Specialists =20 List of Figures Figure 1: The IoT Vision Figure 2: M2M & IoT Network Architecture Figure 3: Global Wide Area M2M Connections by Technology: 2015 =96 2030 Figure 4: Telensa=92s Smart Lighting Solution Figure 5: LoRaWAN Architecture Figure 6: Comparison of Weightless Open LPWA Standards Figure 7: LPWA Networks Industry Roadmap Figure 8: LPWA Networks Value Chain Figure 9: Global LPWA Network Connections: 2015 - 2030 (Millions) Figure 10: Global LPWA Network IoT Service Revenue: 2015 - 2030 ($ Billion) Figure 11: Global LPWA Network IoT Service Revenue by Submarket: 2015 - 203= 0 ($ Billion) Figure 12: Global LPWA Network Connectivity Revenue: 2015 - 2030 ($ Billion) Figure 13: Global LPWA Network IoT Application Service Revenue: 2015 - 2030= ($ Billion) Figure 14: Global LPWA Network Connections by Vertical: 2015 - 2030 (Millio= ns) Figure 15: Global LPWA Network IoT Service Revenue by Vertical: 2015 - 2030= ($ Billion) Figure 16: Global LPWA Network Connections in Agriculture: 2015 - 2030 (Mil= lions) Figure 17: Global LPWA Network IoT Service Revenue in Agriculture: 2015 - 2= 030 ($ Billion) Figure 18: Global LPWA Network Connections in Asset Management & Logistics:= 2015 - 2030 (Millions) Figure 19: Global LPWA Network IoT Service Revenue in Asset Management & Lo= gistics: 2015 - 2030 ($ Billion) Figure 20: Global LPWA Network Connections in Automotive & Transportation: = 2015 - 2030 (Millions) Figure 21: Global LPWA Network IoT Service Revenue in Automotive & Transpor= tation: 2015 - 2030 ($ Billion) Figure 22: Global LPWA Network Connections in Consumer Applications & Home = Automation: 2015 - 2030 (Millions) Figure 23: Global LPWA Network IoT Service Revenue in Consumer Applications= & Home Automation: 2015 - 2030 ($ Billion) Figure 24: Global LPWA Network Connections in Energy & Utilities: 2015 - 20= 30 (Millions) Figure 25: Global LPWA Network IoT Service Revenue in Energy & Utilities: 2= 015 - 2030 ($ Billion) Figure 26: Global LPWA Network Connections in Healthcare: 2015 - 2030 (Mill= ions) Figure 27: Global LPWA Network IoT Service Revenue in Healthcare: 2015 - 20= 30 ($ Billion) Figure 28: Global LPWA Network Connections in Intelligent Buildings & Infra= structure: 2015 - 2030 (Millions) Figure 29: Global LPWA Network IoT Service Revenue in Intelligent Buildings= & Infrastructure: 2015 - 2030 ($ Billion) Figure 30: Global LPWA Network Connections in Public Safety, Security & Sur= veillance: 2015 - 2030 (Millions) Figure 31: Global LPWA Network IoT Service Revenue in Public Safety, Securi= ty & Surveillance: 2015 - 2030 ($ Billion) Figure 32: Global LPWA Network Connections in Retail & Vending: 2015 - 2030= (Millions) Figure 33: Global LPWA Network IoT Service Revenue in Retail & Vending: 201= 5 - 2030 ($ Billion) Figure 34: Global LPWA Network Connections in Other Verticals: 2015 - 2030 = (Millions) Figure 35: Global LPWA Network IoT Service Revenue in Other Verticals: 2015= - 2030 ($ Billion) Figure 36: LPWA Network Connections by Region: 2015 - 2030 (Millions) Figure 37: LPWA Network IoT Service Revenue by Region: 2015 - 2030 ($ Billi= on) Figure 38: Asia Pacific LPWA Network Connections: 2015 - 2030 (Millions) Figure 39: Asia Pacific LPWA Network IoT Service Revenue: 2015 - 2030 ($ Bi= llion) Figure 40: Eastern Europe LPWA Network Connections: 2015 - 2030 (Millions) Figure 41: Eastern Europe LPWA Network IoT Service Revenue: 2015 - 2030 ($ = Billion) Figure 42: Middle East & Africa LPWA Network Connections: 2015 - 2030 (Mill= ions) Figure 43: Middle East & Africa LPWA Network IoT Service Revenue: 2015 - 20= 30 ($ Billion) Figure 44: Latin & Central America LPWA Network Connections: 2015 - 2030 (M= illions) Figure 45: Latin & Central America LPWA Network IoT Service Revenue: 2015 -= 2030 ($ Billion) Figure 46: North America LPWA Network Connections: 2015 - 2030 (Millions) Figure 47: North America LPWA Network IoT Service Revenue: 2015 - 2030 ($ B= illion) Figure 48: Western Europe LPWA Network Connections: 2015 - 2030 (Millions) Figure 49: Western Europe LPWA Network IoT Service Revenue: 2015 - 2030 ($ = Billion) Figure 50: SWOT Matrix: LPWA vs. Competing M2M Networking Technologies Figure 51: Price Breakdown of an LPWA Module =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snscommunication.com Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com