From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 02:45:15 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A27BA9A for ; Sun, 22 Mar 2015 02:45:15 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 58D6FD7D for ; Sun, 22 Mar 2015 02:45:14 +0000 (UTC) Received: (qmail 25343 invoked from network); 22 Mar 2015 02:45:12 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 02:45:12 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 21 Mar 2015 22:45:12 -0400 (EDT) Received: (qmail 13414 invoked from network); 22 Mar 2015 02:45:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 02:45:12 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 23F8B1C439E; Sat, 21 Mar 2015 19:45:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after Date: Sat, 21 Mar 2015 19:45:10 -0700 Message-Id: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: freebsd-current@freebsd.org, pjd@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 02:45:15 -0000 Basic context (more details later): > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 I was seeing what would happen if I tried gcc5 for = buildworld/buildkernel and gcc5 reported the following. The problem: > /usr/local/bin/gcc5 -fpic -DPIC -O2 -pipe -I/usr/srcC/lib/libpjdlog = -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs -Wredundant-decls -Wold-style-definition = -Wno-pointer-sign -c /usr/srcC/lib/libpjdlog/pjdlog.c -o pjdlog.So > In file included from /usr/srcC/lib/libpjdlog/pjdlog.c:44:0: > /usr/include/printf.h:118:44: error: unknown type name 'va_list' > int __xvprintf(FILE *fp, const char *fmt0, va_list ap); > ^ Looking at the sources suggests that is explicitly in the = #include sequence too late to guarantee va_args a definition at the = point of its use in #include : is #include'd in = pjdlog.c in the line after #include and printf.h itself does = not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : > ... > #include > #include /// <<<<< LOOK HERE for lack of > ... > int __xvprintf(FILE *fp, const char *fmt0, va_list ap); > ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message = editing) : > ... > #include > __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 = 09:41:06Z pjd $"); >=20 > #include > #include > #include > #include > #include >=20 > #include > #include > #include > #include > #include /// <<<<< LOOK HERE > #include /// <<<<< LOOK HERE for stdarg.h vs. printf.h = order > #include > #include > #include > #include > #include > #include >=20 > #ifdef notyet > #include > #endif >=20 > #include "pjdlog.h" Context details: make -j 8 \ WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ WITHOUT_LLDB=3D \ WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ WITH_BOOT=3D WITH_LIB32=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 # more /etc/src.conf=20 NO_WERROR=3D WITH_LIBCPLUSPLUS=3D # # # For trying gcc5... # CC=3D/usr/local/bin/gcc5 CXX=3D/usr/local/bin/g++5 CPP=3D/usr/local/bin/cpp5 AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as R=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings # more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite info /usr/ports/lang/gcc5 Path: /usr/ports/lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 06:50:54 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32AD89A4 for ; Sun, 22 Mar 2015 06:50:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 DE895699 for ; Sun, 22 Mar 2015 06:50:53 +0000 (UTC) Received: (qmail 23570 invoked from network); 22 Mar 2015 06:50:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 06:50:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 02:50:51 -0400 (EDT) Received: (qmail 823 invoked from network); 22 Mar 2015 06:50:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 06:50:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 0D1D51C43AF; Sat, 21 Mar 2015 23:50:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r276514's ncurses .vs gcc5-based buildworld: the generated lib_gen.c has problems Date: Sat, 21 Mar 2015 23:50:49 -0700 Message-Id: <65C07062-4CB6-4AAD-B5EC-63A9952CA496@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 06:50:54 -0000 Basic context (more details later): I ran into the below while exploring FreeBSD via a powerpc64 context. = But unlike most things I've run into this is probably not powerpc64 (or = powerpc) context specific. Nor does it appear to be as simple as the = out-of-order and/or incomplete includes issue that I ran into. gcc5 use is not likely where anyone is focused either. Still I figured I'd send out this note about the oddity as a FYI. > # dmesg | head > ... > FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (I used powerpc64-xtoolchain-gcc in a powerpc64 context to self-host, = WITHOUT_CLANG=3D WITHOUT_LLDB=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D = WITHOUT_BOOT=3D WITHOUT_LIB32=3D .) > # freebsd-version -ku; uname -apKU = = 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITH_BOOT=3D WITH_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by the following in order to use gcc5/g++5/... : > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > # > # > # For trying gcc5... > # > CC=3D/usr/local/bin/gcc5 > CXX=3D/usr/local/bin/g++5 > CPP=3D/usr/local/bin/cpp5 > AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as > R=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar > LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld > NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm > OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy > OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump > RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib > SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size > STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings The problem when gcc5 was used: > /usr/local/bin/gcc5 -O2 -pipe -I. = -I/usr/obj/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 = -fstack-protector -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 > _2624.c:754:3: error: "_Bool" after # is not a positive integer > In file included from = /usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv= .h:313:0, > from lib_gen.c:19: > _2624.c:755:2: error: expected ')' before 'int' > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/srcC/lib/ncurses/ncurses > *** Error code 1 Comparing the tail of the generated lib_gen.c from another 11.0-CURRENT = (non-gcc5) tree that I have around... First the tail from that other tree (the normal one): > # tail -20 lib_gen.c | more > T((T_CALLED("getmaxy(%p)"), (const void *)z)); returnCode(((z) = ? ((z)->_maxy + 1) : (-1))); > } >=20 >=20 > NCURSES_EXPORT(int) (getparx) (const WINDOW * z) > { > T((T_CALLED("getparx(%p)"), (const void *)z)); returnCode(((z) = ? (z)->_parx : (-1))); > } >=20 >=20 > NCURSES_EXPORT(int) (getpary) (const WINDOW * z) > { > T((T_CALLED("getpary(%p)"), (const void *)z)); returnCode(((z) = ? (z)->_pary : (-1))); > } >=20 >=20 > NCURSES_EXPORT(NCURSES_BOOL) (mouse_trafo) (int * a1, int * a2, = NCURSES_BOOL z) > { > T((T_CALLED("mouse_trafo(%p,%p,%#lx)"), (const void *)a1, = (const void *)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z)); > } Then the tail for the generated file from the gcc5 based tree (the odd = one): > # tail -20 lib_gen.c >=20 >=20 > NCURSES_EXPORT(int) (getpary) (const WINDOW * z) > { > T((T_CALLED("getpary(%p)"), (const void *)z)); returnCode(((z) ? = (z)->_pary : (-1))); > } >=20 >=20 >=20 > # 753 "_2624.c" 3 4 > NCURSES_BOOL=20 > # 753 "_2624.c" > mouse_trafo (int * a1, int * a2,=20 > # 753 "_2624.c" 3 4 > NCURSES_BOOL=20 > # 753 "_2624.c" > z) > { > T((T_CALLED("mouse_trafo(%p,%p,%#lx)"), (const void *)a1, (const = void *)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z)); > } Context details: # more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite info /usr/ports/lang/gcc5 Path: /usr/ports/lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 09:17:10 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 025A412C for ; Sun, 22 Mar 2015 09:17:09 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 ADACB6DC for ; Sun, 22 Mar 2015 09:17:08 +0000 (UTC) Received: (qmail 10740 invoked from network); 22 Mar 2015 09:17:07 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 09:17:07 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 05:17:07 -0400 (EDT) Received: (qmail 31190 invoked from network); 22 Mar 2015 09:17:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 09:17:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 51A9E1C43AF; Sun, 22 Mar 2015 02:17:05 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A libc++ .depend status mismatch between /usr/src/Makefile.inc1 and bsd.prog.mk for ${X_COMPILER_TYPE} == gcc? Date: Sun, 22 Mar 2015 02:17:04 -0700 Message-Id: <4E9596C3-375E-42DE-ABA3-5066BE3756C5@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 09:17:10 -0000 Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (I used powerpc64-xtoolchain-gcc in a powerpc64 context to self-host, = WITHOUT_CLANG=3D WITHOUT_LLDB=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D = WITHOUT_BOOT=3D WITHOUT_LIB32=3D . powerpc64-xtoolchain-gcc did not = provide itself with a libstdc++ of its own.) > # freebsd-version -ku; uname -apKU = 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > # > # For trying powerpc64-xtoolchain-gcc... > # (Force stages that do not use XCC, XCXX, XCPP to > # also use powerpc64-xtoolchain.gcc's programs.) > # > 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 > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place and the results = depend on > # self-hosting where the two are sufficiently compatibile. > # > # I've used .../. paths below so I can tell use of these from other = sources of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. The problem: /usr/src/Makefile.inc1 has the following code for cross compilation = contexts: > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 > .else > ... In essence having gcc based XCXX cross compilers (X_COMPILER_TYPE) use = libc++'s headers and library for XCXX with gnu++11 (so implicitly c++11) = enabled. libstdc++ is not used. [Note: atf-c++ did did not get automatic header access from the above = for some reason but my /etc/src.conf assignments covered that case.] bsd.prog.mk has the following contrasting code: > .if defined(PROG) > _EXTRADEPEND: > .if defined(LDFLAGS) && !empty(LDFLAGS:M-nostdlib) > .if defined(DPADD) && !empty(DPADD) > echo ${PROG_FULL}: ${DPADD} >> ${DEPENDFILE} > .endif > .else > echo ${PROG_FULL}: ${LIBC} ${DPADD} >> ${DEPENDFILE} > .if defined(PROG_CXX) > .if ${COMPILER_TYPE} =3D=3D "clang" && = empty(CXXFLAGS:M-stdlib=3Dlibstdc++) > echo ${PROG_FULL}: ${LIBCPLUSPLUS} >> ${DEPENDFILE} > .else > echo ${PROG_FULL}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE} > .endif > .endif > .endif > .endif [There is no direct tie between X_COMPILER_TYPE and COMPILER_TYPE in = general but with my /etc/src.conf there is.] In essence (other than -nostdlib and also non-c++ code): Only when COMPILER_TYPE for c++ indicates clang explicitly (without = there being a -stdlib=3Dlibstdc++) is a libc++ dependency written out. = The other c++ cases without -nostdlib always write out a libstdc++ = dependency. My powerpc64-xtoolchain-gcc buildworld buildkernel logs do not show = libc++ additions to .depend files. But they do show the following (from grep activity), although not = necessarily from the above code in every case: echo gperf: /usr/lib/libstdc++.a >> .depend echo grodvi: /usr/lib/libstdc++.a >> .depend echo addftinfo: /usr/lib/libstdc++.a >> .depend echo groff: /usr/lib/libstdc++.a >> .depend echo hpftodit: /usr/lib/libstdc++.a >> .depend echo grn: /usr/lib/libstdc++.a >> .depend ... echo troff: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo hpftodit: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo tests_test: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.tests_test echo indxbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo lkbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo utils_test: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.utils_test echo lookbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo tfmtodit: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo cpp_helpers: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.cpp_helpers echo users: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend Some stale .depend notices for libstdc++.a are also generated (more grep = activity): make[5]: /usr/obj/usr/srcC/libexec/atf/atf-check/.depend, 105: ignoring = stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[5]: /usr/obj/usr/srcC/libexec/atf/atf-sh/.depend, 89: ignoring = stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[4]: /usr/obj/usr/srcC/sbin/devd/.depend, 99: ignoring stale .depend = for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grodvi/.depend, = 34: ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: = /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grohtml/.depend, 151: = ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grolbp/.depend, = 36: ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a ... make[4]: /usr/obj/usr/srcC/usr.bin/users/.depend, 77: ignoring stale = .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: = /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.atf_c++_test, 197: = ignoring stale .depend.atf_c++_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.build_test, = 199: ignoring stale .depend.build_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.check_test, = 204: ignoring stale .depend.check_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.macros_test, = 201: ignoring stale .depend.macros_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.tests_test, = 187: ignoring stale .depend.tests_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.utils_test, = 186: ignoring stale .depend.utils_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: = /usr/obj/usr/srcC/lib/atf/tests/test-programs/.depend.cpp_helpers, 95: = ignoring stale .depend.cpp_helpers for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a Context details: # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h M /usr/srcC/lib/libpjdlog/pjdlog.c ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 12:15:14 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8834DEBD; Sun, 22 Mar 2015 12:15:14 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40EA094F; Sun, 22 Mar 2015 12:15:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::8b7:b034:6f55:4291] (unknown [IPv6:2001:7b8:3a7:0:8b7:b034:6f55:4291]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 66A895C4C; Sun, 22 Mar 2015 13:15:07 +0100 (CET) Subject: Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E5F2705D-23D7-4A2F-932D-D99A3F009B22"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> Date: Sun, 22 Mar 2015 13:14:54 +0100 Message-Id: References: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 12:15:14 -0000 --Apple-Mail=_E5F2705D-23D7-4A2F-932D-D99A3F009B22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Mar 2015, at 03:45, Mark Millard wrote: ... > Looking at the sources suggests that is explicitly in the = #include sequence too late to guarantee va_args a definition at the = point of its use in #include : is #include'd in = pjdlog.c in the line after #include and printf.h itself does = not (directly) include stdarg.h . >=20 > /usr/include/printf.h (the LOOK HERE is my message editing) : >> ... >> #include >> #include /// <<<<< LOOK HERE for lack of >> ... >> int __xvprintf(FILE *fp, const char *fmt0, va_list ap); >> ... >=20 > /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message = editing) : >> ... >> #include >> __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 = 09:41:06Z pjd $"); >>=20 >> #include >> #include >> #include >> #include >> #include >>=20 >> #include >> #include >> #include >> #include >> #include /// <<<<< LOOK HERE >> #include /// <<<<< LOOK HERE for stdarg.h vs. printf.h = order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and includes , which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this "fixed" version of stdio.h: = /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdi= o.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly declare the regular va_list type, and then things break in interesting ways. I think the ports should not attempt to "fix" our include files. -Dimitry --Apple-Mail=_E5F2705D-23D7-4A2F-932D-D99A3F009B22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUOskkACgkQsF6jCi4glqNKewCg5UFKQELcuZRPLKJbKKHaTTqP Td0An1cgQwTBawPobYLzpJ1dWwPfqTsZ =OGfx -----END PGP SIGNATURE----- --Apple-Mail=_E5F2705D-23D7-4A2F-932D-D99A3F009B22-- From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 15:46:06 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4375640D for ; Sun, 22 Mar 2015 15:46:06 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 EE6BAE9A for ; Sun, 22 Mar 2015 15:46:05 +0000 (UTC) Received: (qmail 16847 invoked from network); 22 Mar 2015 15:46:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 15:46:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 11:46:04 -0400 (EDT) Received: (qmail 22936 invoked from network); 22 Mar 2015 15:46:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 15:46:03 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B5B11C43BD; Sun, 22 Mar 2015 08:46:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after From: Mark Millard In-Reply-To: Date: Sun, 22 Mar 2015 08:46:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:46:06 -0000 Dimitry Adnric wrote: > You should be able to include standard headers (or at least, headers = in > /usr/include) in any order, and includes , which > then defines the correct types. Another of the ANSI/ISO-C rules is: You must include a standard header = before you refer to anything that it officially defines or declares. = (The Standard C Library by P. J. Plauger, Copyright 1992, page 7, 3rd = bullet under "using headers".) Part of that status is tied to the following: In a correct ANSI/ISO-C = implementation defines one or more synonyms for va_list using = names from the class of reserved-to-implementation names in order to = declare vprintf, vfprintf, and vsprintf. But does not declare = va_list itself. No ANSI/ISO-C header is allowed to declare/define extra = official-public-name items that are only officially from other headers. = (Page 12.) [There are also 2 more major principles for standard headers: mutual = independence (so order-independence) and idempotent status = (repeatability).] Only is allowed to declare that exact name (va_list) --the = synonym with the official, public name. va_list is one of many things = with this private-name vs public-name synonym structure in ANSI/ISO-C. is not one of the 24 (C99) or so ANSI/ISO-C standard headers = (by name). Nor is __xvprintf from the C standard. So the #include that I referenced is violating the standard by = referring to something from before that header has been = included. The existing source code is in error relative to ANSI/ISO-C. Also: Using the order #include #include in pjdlog.c does get rid of the problem. (As it should, per the above.) But I do not know that there is any official claim that the environment = is to strictly follow ANSI/ISO-C for such points. There may be other = principles instead. How comprehensive/complete is /usr/include header analogy to the = ANSI/ISO-C rules? Does FreeBSD bother with having the private-named = synonyms for headers that do not official declare/define something? Is = FreeBSD as explicit as ANSI/ISO-C about where official definitions are = and are not in headers? (Idempotent headers are the easier part to set = up. Mutual-independence gets into private-named synonym techniques in = order to deal with public names being only in the official places.) (ANSI/ISO-C does have examples of some specific things explicitly being = declared/defined (public names) in more than one header: more examples = where using reserved-name guard macros to gain idempotent status and = order independence can be done.) Note: Much of my background information for this and the terminology = that I use is from The Standard C Library by P. J. Plauger, Copyright = 1992. But I've not noticed any later ANSI/ISO material indicating the = the above has changed status in more recent vintages of the standard. I = could be wrong since I've not tried to be comprehensive about analyzing = changes. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 05:14 AM, Dimitry Andric wrote: On 22 Mar 2015, at 03:45, Mark Millard wrote: ... > Looking at the sources suggests that is explicitly in the = #include sequence too late to guarantee va_args a definition at the = point of its use in #include : is #include'd in = pjdlog.c in the line after #include and printf.h itself does = not (directly) include stdarg.h . >=20 > /usr/include/printf.h (the LOOK HERE is my message editing) : >> ... >> #include >> #include /// <<<<< LOOK HERE for lack of >> ... >> int __xvprintf(FILE *fp, const char *fmt0, va_list ap); >> ... >=20 > /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message = editing) : >> ... >> #include >> __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 = 09:41:06Z pjd $"); >>=20 >> #include >> #include >> #include >> #include >> #include >>=20 >> #include >> #include >> #include >> #include >> #include /// <<<<< LOOK HERE >> #include /// <<<<< LOOK HERE for stdarg.h vs. printf.h = order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and includes , which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this "fixed" version of stdio.h: = /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdi= o.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly declare the regular va_list type, and then things break in interesting ways. I think the ports should not attempt to "fix" our include files. -Dimitry From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 18:46:15 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52BF148F for ; Sun, 22 Mar 2015 18:46:15 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 0B8BD382 for ; Sun, 22 Mar 2015 18:46:14 +0000 (UTC) Received: (qmail 8319 invoked from network); 22 Mar 2015 18:46:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 18:46:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 14:46:13 -0400 (EDT) Received: (qmail 24716 invoked from network); 22 Mar 2015 18:46:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 18:46:13 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id B91D21C43BE; Sun, 22 Mar 2015 11:46:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after From: Mark Millard In-Reply-To: Date: Sun, 22 Mar 2015 11:46:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F203482-E83F-4D32-88FD-E47E1F773971@dsl-only.net> References: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: pjd@FreeBSD.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:46:15 -0000 One point of rather bad wording on my part in the prior note: > private-named synonyms for headers do not official declare/define = something should have been more like (capitalizing replacements/additions): private-named synonyms for things IN THOSE headers that do not = officialLY declare/define them with public names So in its context: Does FreeBSD bother with having the private-named synonyms for things in = those headers that do not officially declare/define them with public = names? (Consider any example of not even needing to name the no-public-name = synonym as an extreme form of private-name, just to make the wording = shorter generally.) I dropped freebsd-current@freebsd.org as not worth moderator activity = for this note. May be I should join but history would suggest I'd have = little activity there. And my activity would likely be too far out of = the ordinary for the use that freebsd-current@freebsd.org is normally = put to. I do not want to interfere with that normal activity when I = happen to have a burst of activity. By contrast freebsd-ppc@freebsd.org (as an example) is not normally very = busy. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 08:46 AM, Mark Millard = wrote: Dimitry Adnric wrote: > You should be able to include standard headers (or at least, headers = in > /usr/include) in any order, and includes , which > then defines the correct types. Another of the ANSI/ISO-C rules is: You must include a standard header = before you refer to anything that it officially defines or declares. = (The Standard C Library by P. J. Plauger, Copyright 1992, page 7, 3rd = bullet under "using headers".) Part of that status is tied to the following: In a correct ANSI/ISO-C = implementation defines one or more synonyms for va_list using = names from the class of reserved-to-implementation names in order to = declare vprintf, vfprintf, and vsprintf. But does not declare = va_list itself. No ANSI/ISO-C header is allowed to declare/define extra = official-public-name items that are only officially from other headers. = (Page 12.) [There are also 2 more major principles for standard headers: mutual = independence (so order-independence) and idempotent status = (repeatability).] Only is allowed to declare that exact name (va_list) --the = synonym with the official, public name. va_list is one of many things = with this private-name vs public-name synonym structure in ANSI/ISO-C. is not one of the 24 (C99) or so ANSI/ISO-C standard headers = (by name). Nor is __xvprintf from the C standard. So the #include that I referenced is violating the standard by = referring to something from before that header has been = included. The existing source code is in error relative to ANSI/ISO-C. Also: Using the order #include #include in pjdlog.c does get rid of the problem. (As it should, per the above.) But I do not know that there is any official claim that the environment = is to strictly follow ANSI/ISO-C for such points. There may be other = principles instead. How comprehensive/complete is /usr/include header analogy to the = ANSI/ISO-C rules? Does FreeBSD bother with having the private-named = synonyms for headers that do not official declare/define something? Is = FreeBSD as explicit as ANSI/ISO-C about where official definitions are = and are not in headers? (Idempotent headers are the easier part to set = up. Mutual-independence gets into private-named synonym techniques in = order to deal with public names being only in the official places.) (ANSI/ISO-C does have examples of some specific things explicitly being = declared/defined (public names) in more than one header: more examples = where using reserved-name guard macros to gain idempotent status and = order independence can be done.) Note: Much of my background information for this and the terminology = that I use is from The Standard C Library by P. J. Plauger, Copyright = 1992. But I've not noticed any later ANSI/ISO material indicating the = the above has changed status in more recent vintages of the standard. I = could be wrong since I've not tried to be comprehensive about analyzing = changes. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 05:14 AM, Dimitry Andric wrote: On 22 Mar 2015, at 03:45, Mark Millard wrote: ... > Looking at the sources suggests that is explicitly in the = #include sequence too late to guarantee va_args a definition at the = point of its use in #include : is #include'd in = pjdlog.c in the line after #include and printf.h itself does = not (directly) include stdarg.h . >=20 > /usr/include/printf.h (the LOOK HERE is my message editing) : >> ... >> #include >> #include /// <<<<< LOOK HERE for lack of >> ... >> int __xvprintf(FILE *fp, const char *fmt0, va_list ap); >> ... >=20 > /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message = editing) : >> ... >> #include >> __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 = 09:41:06Z pjd $"); >>=20 >> #include >> #include >> #include >> #include >> #include >>=20 >> #include >> #include >> #include >> #include >> #include /// <<<<< LOOK HERE >> #include /// <<<<< LOOK HERE for stdarg.h vs. printf.h = order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and includes , which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this "fixed" version of stdio.h: = /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdi= o.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly declare the regular va_list type, and then things break in interesting ways. I think the ports should not attempt to "fix" our include files. -Dimitry From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 17:26:45 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B727BEAE for ; Mon, 23 Mar 2015 17:26:45 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 4FA40E6B for ; Mon, 23 Mar 2015 17:26:44 +0000 (UTC) Received: (qmail 3052 invoked from network); 23 Mar 2015 17:00:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Mar 2015 17:00:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 23 Mar 2015 13:00:03 -0400 (EDT) Received: (qmail 23977 invoked from network); 23 Mar 2015 17:00:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Mar 2015 17:00:03 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 7DCB11C43A6; Mon, 23 Mar 2015 09:59:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An Error" when compiling clang and stops the build From: Mark Millard In-Reply-To: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> Date: Mon, 23 Mar 2015 10:00:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C8146E7-B814-4F40-BEB0-224CF79C0BBD@dsl-only.net> References: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:26:45 -0000 https://llvm.org/bugs/show_bug.cgi?id=3D22771 from Dimitry Andric's = submittal of the problem indicates that the libc++ code is not a = "Substitution Failure Is Not An Error" context and so is wrong. (C is = certainly simpler than C++ for identifying what applies where.) They have an improvement but Richard Smith's tiny test case shows it is = not yet correct: > Here's a testcase that fails with Clang: >=20 > #define __has_feature(x) 0 > #include > class X { X(const X&); }; > bool b =3D std::is_convertible::value; >=20 > (Using a public deleted copy constructor fails similarly.) in that both the original code and the improvement fail to compile the = above but instead treat it as an error. (Dimitry Andric tested the = improvement and https://llvm.org/bugs/show_bug.cgi?id=3D22771 shows the = error that he got.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-20, at 11:27 PM, Mark Millard = wrote: Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by: > # more /etc/src.conf > 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 > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. > # > NO_WERROR=3D The problem: (Somewhat reformatted text...) > In file included from /usr/include/c++/v1/./algorithm:625:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringRef.h:13, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:17, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > /usr/include/c++/v1/./type_traits: >=20 > In instantiation of 'struct std::__1::__is_convertible&, = llvm::StringMap, 0u, 0u>': > /usr/include/c++/v1/./type_traits:943:62: > required from >=20 > 'struct std::__1::is_convertible&, = llvm::StringMap >' > /usr/include/c++/v1/./utility:269:77: > required by >=20 > substitution of 'template std::__1::pair<_T1, = _T2>::pair(const std::__1::pair<_U1, _U2>&, typename = std::__1::enable_if<(std::__1::is_convertible::value && = std::__1::is_convertible::value)>::type*) [with _U1 =3D = llvm::StringRef; _U2 =3D llvm::StringMap]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:371:55: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef, = InitTy) [with InitTy =3D llvm::StringMap; = ValueTy =3D llvm::StringMap; AllocatorTy =3D= llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:375:43: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef) = [with ValueTy =3D llvm::StringMap; = AllocatorTy =3D llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:299:32: > required from >=20 > 'ValueTy& llvm::StringMap::operator[](llvm::StringRef) [with ValueTy =3D = llvm::StringMap; AllocatorTy =3D = llvm::MallocAllocator]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:120:21: > required from >=20 > here > /usr/include/c++/v1/./type_traits:881:87: error: use of deleted = function 'llvm::StringMap::StringMap(const = llvm::StringMap&)' > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) =3D=3D 1 > = ^ and a little more... > In file included from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:226:7: > note: 'llvm::StringMap::StringMap(const = llvm::StringMap&)' is implicitly declared = as deleted because 'llvm::StringMap' = declares a move constructor or move assignment operator > class StringMap : public StringMapImpl { > ^ where... > namespace __is_convertible_imp > { > template char __test(_Tp); > template __two __test(...); > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > template _Tp&& __source(); > #else =20 > template typename remove_reference<_Tp>::type& __source(); > #endif >=20 > ... > } In other words: > __is_convertible_imp::__source&>() is a function returning llvm::StringMap&& = (an r-value reference, not a universal one). (I'm presuming rvalue = references but the overall point is the same even for const = llvm::StringMap& as the return type.) As for __is_convertible_imp::__test: > = __is_convertible_imp::__test= > > (llvm::StringMap) is a function returning a value of type char that is used when the = argument can be passed into a = llvm::StringMap type of parameter. Failure = of this to be possible is not of itself an error ("substitution failure = is not an error" for selecting template functions): it just means that = other example definitions of __is_convertible_imp::__test functions may = be used to match the argument instead. and > = __is_convertible_imp::__test= >(...) is a function returning a value of type __two for all potential, valid = argument lists. (_T2 is actually ignored.) When both = __is_convertible_imp::__test's are non-errors the prior one is picked by = the language rules: a better parameter vs. argument match. Note that the status of deleted copy constructors can contribute to if > = __is_convertible_imp::__test= > > (llvm::StringMap) is a match for the convertibility classifications and it is not an error = for them to do so. The size of the selected = __is_convertible_imp::__test= >'s result type indicates the is-convertible status (sizeof(char) !=3D = sizeof(__two)) and the sizeof use means that overall the expression is a = constexpr (compile time constant) that is based on the type analysis by = the compiler, with no actual constructions happening. But the powerpc64-gcc 4.9.1 compiler is not applying the principle of = "substitution failure is not an error" and is not using the implicitly = deleted-status to cause a mis-match for: > = __is_convertible_imp::__test= > > (llvm::StringMap) So the compiler rejects the code for supposed use of an implicitly = deleted StringMap(const StringMap &RHS) constructor. This is a wrong = classification for the code. It appears that powerpc64-gcc (gcc 4.9.1) is not up to compiling = 11.0-CURRENT -r279514's clang/llvm as-is. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > 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 > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #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 > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # 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: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 18:26:28 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1E06522; Mon, 23 Mar 2015 18:26:27 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B38117E5; Mon, 23 Mar 2015 18:26:27 +0000 (UTC) Received: by obbgg8 with SMTP id gg8so129707154obb.1; Mon, 23 Mar 2015 11:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+Z3HP7AkGyG3HEPharCgLTTNQ2HLsXjyt2Kmf0u5NAM=; b=L+km4hUnljVQk41hm5Dki1JFv+RwD1/lK1WUFt/En0BmkSSONn1TLT5ljKS0InUwLr eRc3y3jGCurUijZCoJJv2bR3lAWYhVGAJAu/dfrgXtYqMOSbDEUpvRMK/V6NmmXxn3uz 7ofGqimxRWLeGdbMxTPWf5YAvDN/y4vA20Cno43lYD2vmNKLxNqhaX6IYwUCpc/CWeu8 8qjf+XsNuqcKICOmX2+hhYpXq0iwW4l+yLLxPFQsIHnwjI4BdQBqolucjT8m7XiYhDXY b+A7OyfaFCIWMkEAT8en4VpkCHazRZUkcGm/a2sIA4v/f5qPEq2esBj6R1mP8CSZ+sWS gLnQ== MIME-Version: 1.0 X-Received: by 10.202.230.69 with SMTP id d66mr414847oih.8.1427135187005; Mon, 23 Mar 2015 11:26:27 -0700 (PDT) Received: by 10.182.248.164 with HTTP; Mon, 23 Mar 2015 11:26:26 -0700 (PDT) Date: Mon, 23 Mar 2015 14:26:26 -0400 Message-ID: Subject: Time to be real From: Joe Nosay To: freebsd-current , FreeBSD PowerPC ML , FreeBSD Hackers , FreeBSD Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:26:28 -0000 Go to hell. Go fuck yourselves. From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 19:07:19 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2149DB00; Mon, 23 Mar 2015 19:07:19 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id F3452CE9; Mon, 23 Mar 2015 19:07:18 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id A3052A041; Mon, 23 Mar 2015 14:07:17 -0500 (CDT) Date: Mon, 23 Mar 2015 14:07:17 -0500 From: Mark Linimon To: Joe Nosay Subject: Re: Time to be real Message-ID: <20150323190717.GA497@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , freebsd-current , FreeBSD Mailing List , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:07:19 -0000 Thank you for your troll. For your convenience, we will do our best not to reply to you any further, to waste either your time, or valuable electrons. mcl From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 20:13:56 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80E79830; Mon, 23 Mar 2015 20:13:56 +0000 (UTC) Received: from biertje.skysmurf.nl (unknown [IPv6:2001:984:78b5:1:21b:78ff:fea8:3f22]) (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 18BFA7D8; Mon, 23 Mar 2015 20:13:55 +0000 (UTC) Received: from biertje.skysmurf.nl (localhost [127.0.0.1]) by biertje.skysmurf.nl (8.14.9/8.14.9) with ESMTP id t2NKDqYV002578; Mon, 23 Mar 2015 21:13:52 +0100 (CET) (envelope-from fonz@biertje.skysmurf.nl) Received: (from fonz@localhost) by biertje.skysmurf.nl (8.14.9/8.14.9/Submit) id t2NKDqmF002577; Mon, 23 Mar 2015 21:13:52 +0100 (CET) (envelope-from fonz) Date: Mon, 23 Mar 2015 21:13:52 +0100 From: "A.J. \"Fonz\" van Werven" To: Mark Linimon Subject: Re: Time to be real Message-ID: <20150323201352.GA2555@biertje.skysmurf.nl> References: <20150323190717.GA497@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20150323190717.GA497@lonesome.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD PowerPC ML , freebsd-current , FreeBSD Mailing List , FreeBSD Hackers X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:13:56 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark Linimon wrote: > to waste either your time, or valuable electrons. Come now, electrons are overrated. They come with every occurance of beta(-negative) decay. In fact, the intermediate negative W-boson that gives you said electron also gives you an electron antineutrino, entirely free of charge :-) AvW --=20 I'm not completely useless, I can be used as a bad example. --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVEHP/AAoJEAfP7gJTaCe87rYQANx4drJI1XTfOg8BE4N1cVb9 K6gDOpzB/SasOQgxDSXVrVJc6xGQcxBMojA+4H/oBG39U2stNfH4uWY4OEC8RsVx RGRiq1XWWOc+yphEygA7afDnHvdRq1SZh3ds41HWu337b0JQlb0/0gtMtsijw4cd cQHlEL+IQIkwySwvH9J58I4vBybFXEViM9KhSXiLGN+V7ou3BG/5SoN9z+ihCTCz hRPvJ3Nl6kGzRIm7YAjXQKrip/EktpRYv8utQDMIlHlC3YtKV7F88EbPPWSg3kR7 xtTthup3oXze+JHH0Fb2aHJDUV4ddebyDCZQ7AXUWmgDsJjtq5713HnoE9Lr8x6j 9X6mVsQKokWM2DUeHCJuWPGA3tLFGpV/pzavPPC3Btvsojz0w6tETIZFKTR2Uamb Leoh8hW9wBz/KupJhrTMaNytAIN8zNQYHsi2IJQ+Yq1FXNKe61DSE2D84BramgSH ktuRFMnW8uqFEQMUFmTQjwIqUW3G/xDbI4NHPpzobU0AaPkIXt+GIrNYqldKNCCq CERKSxabITfMbNDzpgKmhCxCh1YWN55gywsn0hm9RZZM3qn6PgqnZ5StYPGhcTcs xivhr/HM3VwuJT5oWQDLhiEjGIEgslVtNWf78TUowRbRJEy84gdaxaRsVbpKV8qx IKmHeNC0OamxSO50kZSQ =Vbh3 -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 20:28:34 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEC9BD5B; Mon, 23 Mar 2015 20:28:34 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id C806D916; Mon, 23 Mar 2015 20:28:33 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLO00I4OMG31700@hades.sorbs.net>; Mon, 23 Mar 2015 13:33:41 -0700 (PDT) Message-id: <55107768.7020301@sorbs.net> Date: Mon, 23 Mar 2015 21:28:24 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: "A.J. \"Fonz\" van Werven" Subject: Re: Time to be real References: <20150323190717.GA497@lonesome.com> <20150323201352.GA2555@biertje.skysmurf.nl> In-reply-to: <20150323201352.GA2555@biertje.skysmurf.nl> Cc: FreeBSD Hackers , freebsd-current , FreeBSD Mailing List , Mark Linimon , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:28:35 -0000 A.J. "Fonz" van Werven wrote: > Mark Linimon wrote: > > >> to waste either your time, or valuable electrons. >> > > Come now, electrons are overrated. There's a lot of negativity over electrons here... -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 20:36:22 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63AD9ECF; Mon, 23 Mar 2015 20:36:22 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 273369ED; Mon, 23 Mar 2015 20:36:22 +0000 (UTC) Received: by igbud6 with SMTP id ud6so53873310igb.1; Mon, 23 Mar 2015 13:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=amb4RtO2lKI8w5EoxrvUHaomhQI+/DW8yskQiOLsRW0=; b=GXUombd/4JOUia+jh1A3TkLC0OK94j7xjRXkQuD0dHM99pdLi4ki4LoALf13xkyO8r J4n4r9RKL0NclXfOfOJ2dYXRrpLOX3NDgQV3yTiWdV97sQZmrrhl6lU/jWjsWVkUDt1G D3x5O4OndqRmTxvahuD1klIVhm/MpolJT4JVqIR8EfvPlhkgLlQbt+aZFmKpS988IVYG dKCpAu5xUuy6SFqTKXT9RnaUtqu5nxzjcHzkV0ZyDEX2Z5XTkZTgeb//n3/bqYkfDtSh A+MLGxanJooaeTtyNEDXjpMBJ1HAjZgaJqMCZSMdfikEwaXWxpSgsOKAVAQRzc9mTgRh w4Hw== MIME-Version: 1.0 X-Received: by 10.43.66.131 with SMTP id xq3mr22493326icb.9.1427142981616; Mon, 23 Mar 2015 13:36:21 -0700 (PDT) Received: by 10.50.4.165 with HTTP; Mon, 23 Mar 2015 13:36:21 -0700 (PDT) In-Reply-To: <55107768.7020301@sorbs.net> References: <20150323190717.GA497@lonesome.com> <20150323201352.GA2555@biertje.skysmurf.nl> <55107768.7020301@sorbs.net> Date: Mon, 23 Mar 2015 16:36:21 -0400 Message-ID: Subject: Re: Time to be real From: Nemo To: Michelle Sullivan Content-Type: text/plain; charset=UTF-8 Cc: "A.J. Fonz van Werven" , FreeBSD Hackers , freebsd-current , FreeBSD Mailing List , Mark Linimon , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:36:22 -0000 On 23 March 2015 at 16:28, Michelle Sullivan wrote: > A.J. "Fonz" van Werven wrote: >> Mark Linimon wrote: >>> to waste either your time, or valuable electrons. >> Come now, electrons are overrated. > There's a lot of negativity over electrons here... Not to worry, Electon Bob was vanquished a long time ago by Norm Walker. From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 21:02:34 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B30948F4 for ; Mon, 23 Mar 2015 21:02:34 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78A48D4D for ; Mon, 23 Mar 2015 21:02:34 +0000 (UTC) Received: by obdfc2 with SMTP id fc2so133034798obd.3 for ; Mon, 23 Mar 2015 14:02:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lntPXRyQwdIhg8+SexiWFMXTR16Vvb+3UAd8+dT+JFo=; b=FJHGsyyw6jiwXMDspwv1gLEGXn12V6F4cIYYCxqvB0ynffyd6QC76EAjcTiI5uIiBN Di9YGIplAEV0T3opst2/7Ir0pibnk87VUF8LU9ntTlFgqO87akEHTtV8NqwIHdF8WzGP 0SXVdAVh7BOoI7Zb0hDcuykZ8RMRORl4vL+UFoo8/V18oV+66agPCsZGy4WWFDLOSOS2 Aq/6KR9hBH6HZYzATAcHxW4F/wYsCRLw8FGeaoAN6jXqGH6o9Dlx7sT+tOSQrycOlSvK FmToO6NYiB5JbVHFU5/3r2HEbTXfRragZHgu1J1Fw/QZs7FpcDw9muWZan1GV8dAOhqY KPnQ== X-Gm-Message-State: ALoCoQlLX4usfplRPebyABPhjyZfqbHmUG1ftDj9Zba7NvRiNh2pNLsQhWuVvjRMD5YNAD96BxCj MIME-Version: 1.0 X-Received: by 10.182.79.199 with SMTP id l7mr867572obx.46.1427144147406; Mon, 23 Mar 2015 13:55:47 -0700 (PDT) Received: by 10.202.189.133 with HTTP; Mon, 23 Mar 2015 13:55:47 -0700 (PDT) Received: by 10.202.189.133 with HTTP; Mon, 23 Mar 2015 13:55:47 -0700 (PDT) In-Reply-To: References: <20150323190717.GA497@lonesome.com> <20150323201352.GA2555@biertje.skysmurf.nl> <55107768.7020301@sorbs.net> Date: Mon, 23 Mar 2015 16:55:47 -0400 Message-ID: Subject: Re: Time to be real From: Black Fox To: freebsd-ppc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:02:34 -0000 I'm not going to waste a single CPU cycle passed what was used to make this email. Go play on your GNU box of choice and eat a dick, Joe Nosay or else Super Bisquit. On Mar 23, 2015 4:36 PM, "Nemo" wrote: > On 23 March 2015 at 16:28, Michelle Sullivan wrote: > > A.J. "Fonz" van Werven wrote: > >> Mark Linimon wrote: > >>> to waste either your time, or valuable electrons. > >> Come now, electrons are overrated. > > There's a lot of negativity over electrons here... > > Not to worry, Electon Bob was vanquished a long time ago by Norm Walker. > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 21:14:33 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18447ED7; Mon, 23 Mar 2015 21:14:33 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 E1850E5E; Mon, 23 Mar 2015 21:14:32 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2NL89Gp052297; Mon, 23 Mar 2015 14:08:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: freebsd-current , FreeBSD PowerPC ML , FreeBSD Hackers , FreeBSD Mailing List In-Reply-To: References: From: "Chris H" Subject: Re: Time to be real Date: Mon, 23 Mar 2015 14:08:54 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:14:33 -0000 On Mon, 23 Mar 2015 14:26:26 -0400 Joe Nosay wrote _____________________________ /____________________________/| | ___ || | /__/| || | PLEASE | || || | | || || | DO NOT FEED | || || | |__|/ || | THE TROLLS ___ || | /__/| || | |__|/ || |____________________________|/ | || | ||/| |\|/\||/| ________/\// /\/ |_____________ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 23 22:55:55 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20F6CB01; Mon, 23 Mar 2015 22:55:55 +0000 (UTC) Received: from mail-out.smeets.im (mail-out.smeets.im [5.9.17.157]) (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 C177BB81; Mon, 23 Mar 2015 22:55:54 +0000 (UTC) Received: from mail.smeets.im (mail.smeets.im [IPv6:2a01:4f8:160:918a::25:3]) by mail-out.smeets.im (Postfix) with ESMTP id 30D9613D0; Mon, 23 Mar 2015 23:55:46 +0100 (CET) Received: from amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) by mail.smeets.im (Postfix) with ESMTP id B1144892AF; Mon, 23 Mar 2015 23:55:46 +0100 (CET) X-Virus-Scanned: amavisd-new at smeets.im Received: from mail.smeets.im ([IPv6:2a01:4f8:160:918a::25:3]) by amavis.smeets.im (amavis.smeets.im [IPv6:2a01:4f8:160:918a::aa:4]) (amavisd-new, port 10025) with ESMTP id IM0x-EBallLC; Mon, 23 Mar 2015 23:55:46 +0100 (CET) Received: from nibbler-wlan.home.lan (unknown [85.22.28.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.smeets.im (Postfix) with ESMTPSA id 0CFFF89287; Mon, 23 Mar 2015 23:55:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=smeets.im; s=default; t=1427151346; bh=wzjfAI8SnrISTLRGX19ytl4rEYHaZEODHnqpTr5Udto=; h=Subject:To:references:From:Date:in-reply-to; b=kutD6pJylQBUYXFARnuDnVu95CpEgm7ILbiBGFZC9HfDLOl4mGCJUfpc/GhNx3Yu3 ttYaF0BwfL7LXqYNZMvOM2/kHPP4SEjP1tkTvLtY/qherX/nmadmu1shgV5br08uEp aCctdQpZYc3moR7ncKovIU3e6PZhRs3/vBoPqNew= Subject: Re: Time to be real To: Joe Nosay , freebsd-current , FreeBSD PowerPC ML , FreeBSD Hackers , FreeBSD Mailing List , postmaster@FreeBSD.org references: From: Florian Smeets message-id: <551099EF.60606@smeets.im> Date: Mon, 23 Mar 2015 23:55:43 +0100 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0a2 mime-version: 1.0 in-reply-to: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QiLcX1B4EWATpqjQXNOcBHiknGSwbaaap" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:55:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QiLcX1B4EWATpqjQXNOcBHiknGSwbaaap Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Joe has indicated in the past that SPAM was sent from his account: https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095407.h= tml We (postmaster@) contacted Joe and are looking into the issue. Please do not reply to the thread anymore. Florian --QiLcX1B4EWATpqjQXNOcBHiknGSwbaaap Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJVEJnvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNzAxMDMyMDNCQ0FCNDRBOThGRUM4NDRF NzA1M0RGOUZGODZGMDc2AAoJEOcFPfn/hvB2rvAQAItSKctjP+p57HkCDl/IEh80 fRIkU+z6NJwEC11kybV2md/tyFT+pKSLCFGPsUx7H8+X31Z0neabkNkJFUeeNn2+ irfnuLy3tw3jV9CC2CJcQoLLcVVWrLlOzXqW2O0uBx4vNAFAg+XF7s66T/6K19Lq c2WCN3F/2Qch27QiK0I5vCTUhEcb14Uk994KZnJx3pkTTnVTx4yQ1TSN1FPIDRlh 5As0GuD0M52ORAG1iZ5Fat4T9nit1omxV0cfPJqiqy3uM9cofoutvz8FjT8lTn+1 vKq2Ba23dOJQk1fxfIc4v51/21DFYSAqcV2c6SfsKB8Zicua/aZKz84vhLfbdYm9 sZ6Kdb8WL3LuboUc5Sj2utdpH8XouVJQA4F0ChCIHvcxsUNLhnl22CFumqc/RZ13 GE1bp/pGUpymlJDHSXZndyLSsZUvH+608eMTJQwYiUybro8BeMX0Nomc0iW2GCbN PRZH3ivRE27NsoONSa4TZRQUVL6Qs9DyEHDSjkLvD4b+J0pYncWRzV7EExAUzk5b bJbVdKC+OWZsSA20XJGl3RVQsLym8FFvmkLa7dVTCX258QPDP3W9YW5kudibirGv dfQCvMvyLykZjzlNYUTXTWSkzDoeGDn2FHlax6eBGAVPLvmdqSMd1EEYrnMW8LHR FK1HZijS3Qhwkrb3ypV/ =+A9w -----END PGP SIGNATURE----- --QiLcX1B4EWATpqjQXNOcBHiknGSwbaaap-- From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 24 05:47:27 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74759B67 for ; Tue, 24 Mar 2015 05:47:27 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 D2794C70 for ; Tue, 24 Mar 2015 05:47:25 +0000 (UTC) Received: (qmail 5316 invoked from network); 24 Mar 2015 05:47:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2015 05:47:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 24 Mar 2015 01:47:19 -0400 (EDT) Received: (qmail 26159 invoked from network); 24 Mar 2015 05:47:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2015 05:47:18 -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 Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 87ED21C43A2; Mon, 23 Mar 2015 22:47:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests] From: Mark Millard In-Reply-To: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> Date: Mon, 23 Mar 2015 22:47:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> To: rodrigc@FreeBSD.org, Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 05:47:27 -0000 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html has = the following note about std::is_convertible : > Library implementor's note: Except for the protected/private access = checks, and the ambiguity checks, this specification is completely = implementable in C++03 (even without rvalue references). However it is = intended that this be implemented with compiler help to get the access = and ambiguity checks correct. This note would seem to apply to examples like Richard Smith's tiny test = case listed in https://llvm.org/bugs/show_bug.cgi?id=3D22771 : > Here's a testcase that fails with Clang: >=20 > #define __has_feature(x) 0 > #include > class X { X(const X&); }; > bool b =3D std::is_convertible::value; >=20 > (Using a public deleted copy constructor fails similarly.) It sounds like there are going to be limitations to any library-only = solution (i.e., to any fallback implementation of std::is_convertible). So for a failing fallback test example to matter likely requires that = the failure not depend on accessibility checks or ambiguity checks. Might it be that the improvement that was being tested is sufficient = given the general limitations on library-only code solutions? Going the other way: if one wants code (such as llvm/clang source) to = survive environments that need to use a library-only fallback then that = code needs to avoid depending on accessibility or ambiguity properties = for its direct or indirect use of std::is_convertible. I do not know = what criteria llvm/clang uses for such issues. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 09:56 PM, Mark Millard = wrote: I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and = its powerpc64-gcc port: use of CROSS_TOOLCHAIN=3Dpowerpc64-gcc used on a = powerpc64. No solution, just notes about what was going on after looking = at the source code related to the messages. If you care, see: > CROSS_TOOLCHAIN=3Dpowerpc64-gcc mishandles "Substitution Failure Is = Not An Error" when compiling clang and stops the build ( = https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.ht= ml ) > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) > =3D=3D 1 is the core place involved in your example and mine but the order of = compilation for my context means a different starting place that ended = up using the above. lang/gcc5 did the same when I later tried it. I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt = xtoolchain vs. normal port matters. I expect that the issue spans a = range of g++ versions. Unfortunately that probably also means that the effectively = "Substitution Failure of this kind Is An Error" rule now in use will = probably be around for a while: it is likely not some local accident = that has a quick fix. The best case is if it is simple but each = version/variant needs to release with the change. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 24 10:34:06 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37F20B8D for ; Tue, 24 Mar 2015 10:34:06 +0000 (UTC) Received: from swatch.464695.com (swatch.464695.com [104.148.9.119]) by mx1.freebsd.org (Postfix) with ESMTP id D969DF7A for ; Tue, 24 Mar 2015 10:34:05 +0000 (UTC) To: freebsd-ppc@freebsd.org Subject: Are you interested in photo retouching? Message-ID: <5d12d0282873a292739b8ee54ab0c233@lowes.com> Date: Tue, 24 Mar 2015 08:35:35 +0100 From: "Harry" Reply-To: dinglingcon@sina.com MIME-Version: 1.0 X-Mailer-LID: 5 X-Mailer-RecptId: 6480531 X-Mailer-SID: 171 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 10:34:06 -0000 How are you? Are you interested in photo retouching or other photo editing solutions? We specialize in providing below photo retouching services: Photoshop photos editing/retouching Jewelry photos retouching Ecommerce products photo editing Photo cutting out/clipping path Beauty/skin retouching, Wedding photo editing and photo background manipulation. You can send us a photo for free testing and check our quality Waiting for your soonest response. Best regards, Harry Email: markedit@tom.com From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 25 21:27:11 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E12408BA for ; Wed, 25 Mar 2015 21:27:10 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (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 995FE617 for ; Wed, 25 Mar 2015 21:27:09 +0000 (UTC) Received: (qmail 19046 invoked from network); 25 Mar 2015 21:20:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Mar 2015 21:20:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 25 Mar 2015 17:20:29 -0400 (EDT) Received: (qmail 31358 invoked from network); 25 Mar 2015 21:20:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Mar 2015 21:20:28 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 6F8091C43AE; Wed, 25 Mar 2015 14:20:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r279514's lib/csu/powerpc64/ vs. cross builds/port builds Date: Wed, 25 Mar 2015 14:20:26 -0700 Message-Id: <52A95085-A438-4503-BCB3-0D07DDE89F9C@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:27:11 -0000 I've been experimenting with buildworld/buildkernel based on = powerpc64-xtoolchain-gcc (and with lang/gcc49) used under powerpc64 and = under powerpc builds. I started from the special case of working under = powerpc64 11.0-CURRENT (a self hosting cross compile for = powerpc64-xtoolchain-gcc use). Then I switched to starting from powerpc = (non-64) 11.0-CURRENT. Overall this results in 3 lib/csu/powerpc64/... subject area for notes = so far... The first one is based on: > # XXX: See the log for r232932 as to why the above -mlongcall is = needed. Since > # clang doesn't support -mlongcall, and testing shows a clang linked = with a > # clang-built csu segfaults, this must currently be compiled with gcc. = Once > # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. > CC:=3D gcc > COMPILER_TYPE:=3D gcc This is forcing of using the path's first-found "gcc" (typically the = system's 4.2.1). This overrides any XCC assignment for a cross tool = chain and also overrides CC assignments for ports based that would pick = out a gcc compiler instead of clang (such as lang/gcc49's 4.9.3). I would expect that this sort of thing should be conditional on clang = being in use --if cross compilers and ports-based builds are to be = supported. (I may well have wondered outside where this tier 2 environment intends = to go.) Note: 10.1-STABLE does not have the forced gcc usage in its = lib/csu/powerpc64/Makefile. Just to continue my experiment I changed the CC assignment to find the = gcc that I was trying to use in order to see what else might show up. A second subject area is: Even when the host/default gcc or other gcc is = to be used it would need to be told of the target environment, both for = C compiles and for assembler use. Currently this does not happen when = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 is used from a powerpc (non-64) = host. If from powerpc (non-64) I try to build for powerpc64 I get complaints = about assembler notation associated with TOC use and notation that has @ = (at sign) in use. =46rom machine/asm.h there is the definition of the = notation: > #ifdef __powerpc64__ > #define TOC_REF(name) __CONCAT(.L,name) > #define TOC_ENTRY(name) \ > .section ".toc","aw"; \ > TOC_REF(name): \ > .tc name[TC],name >=20 > #define _ENTRY(name) \ > .section ".text"; \ > .p2align 2; \ > .globl name; \ > .section ".opd","aw"; \ > .p2align 3; \ > name: \ > .quad DOT_LABEL(name),.TOC.@tocbase,0; \ > .previous; \ > .p2align 4; \ > TYPE_ENTRY(name) \ > DOT_LABEL(name): >=20 > #define _END(name) \ > .long 0; \ > .byte 0,0,0,0,0,0,0,0; \ > END_SIZE(name) > #else /* !__powerpc64__ */ > #define _ENTRY(name) \ > .text; \ > .p2align 4; \ > .globl name; \ > .type name,@function; \ > name: > #define _END(name) > #endif /* __powerpc64__ */ The lack of __powerppc64__ being defined explains the parsing problems = when the host is powerpc (non-64), despite TARGET_ARCH=3Dpowerpc64 use. = (I've not dealt with this issue yet.) I'll note that the TOC related parsing issue exists outside /lib/csu/... = as well, such as assembling lib/libc/powerpc64/sys/brk.S . So this may = not be a local lib/csu/... problem with just a local solution for using = powerpc (non-64) builds to target TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64. =46rom looking around it seems that this subject area might well also = apply to 10.1-STABLE. A 3rd subject area is picking files from /usr/include/sys/ and = /usr/include/machine/ by default vs. from ${WORLDTMP}/usr/include/sys/ = and ${WORLDTMP}/usr/include/machine/ vs. not finding various files at = all. As stands the CFLAGS are assigned by: > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include \ > -mlongcall Looking where that suggests for libc... > # ls lib/libc/include=20 > block_abi.h errlst.h isc namespace.h = nscachedcli.h port_after.h reentrant.h spinlock.h > compat.h fpmath.h libc_private.h nscache.h = nss_tls.h port_before.h resolv_mt.h un-namespace.h >=20 libc_private.h is used and is not in /usr/include/ or in = ${WORLDTMP}/usr/include. So there is a reason to reference this area. But there is use of (via grep): > lib/csu/powerpc64/crt1.c:#include > lib/csu/powerpc64/crti.S:#include > lib/csu/powerpc64/crtn.S:#include which are not covered by the -I's directory trees and were not found for = the cross compiler usage. For the powerpc (non-64) host gcc it implicitly looks in /usr/include = areas but cross compilers and ports compilers are not likely to look = there automatically, more likely looking someplace like = /usr/local/include which has no /usr/local/include/sys/ or = /usr/local/include/machine/ . Grabbing machine/asm.h from the host machine type's = /usr/include/machine/asm.h could be way wrong when the host in not a = powerpc variant. Both sys/cdefs.h and machine/asm.h could have old-vintage issues from = using /usr/include/ instead of ${WORLDTMP}/usr/include/ as the basis for = finding the files. (I'm not claiming likely changes.) I used the following to get rid of those missing-include errors for a = compiler/assembler that does not automatically look in /usr/include/ : > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${WORLDTMP}/usr/include \ > -I${.CURDIR}/../../libc/include \ > -mlongcall That used where libc_private.h is only when a file is not found in the = more normal ${WORLDTMP}/usr/include/... area. Of course when the host = gcc is used /usr/include/... is still potentially referenced. I have not tried any use of --sysroot or other such to control the = behavior. What I did may not have the best of behaviors. Parts of this subject area likely applies to the 10.1-STABLE context as = well form what I see looking its Makefile. I've not dealt with the __powerpc64__-missing issues for TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64 on powerpc (non-64) yet. That could be masking = more things for me to find. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 26 16:49:12 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53A7646E; Thu, 26 Mar 2015 16:49:12 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E67AF656; Thu, 26 Mar 2015 16:49:11 +0000 (UTC) Received: by labe2 with SMTP id e2so50316594lab.3; Thu, 26 Mar 2015 09:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=B6n/6Erp2xYYjpUpw/1OxDXCqsIeJ/usPA0L0Bw27FA=; b=Psi1NttnLocGFAB68DrW7tMvMqub+2hU2TVPxNNKvyDYazdY1jyxKQDWhrsKLhcbmF tM4+aAuopBCai8UeMqigIrr0Sk3I/sVZ0iS23TrmvdwzYEV++W4ydG2u18KURmjnCHco eXl14ENRKdFyn9fPUOLZlxHgude9VSztnilUto8VFx5Ypaj8uQcRskF7uZ5zI53LgZ4f C9yNJ9ZepEbYxnu1muvD1LYZrFZ9t1n9HlQctpz8KTtRGuawONPvfa9pqxyYbLnwiAkw 7bqrtDtIrKTa0QU4ywPZhNVfOp+2RZlmZScem5K/TVBTyOhDaOPpkqO9xhqiHGlP3s63 3dcQ== MIME-Version: 1.0 X-Received: by 10.112.212.106 with SMTP id nj10mr14135425lbc.36.1427388550077; Thu, 26 Mar 2015 09:49:10 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.145.205 with HTTP; Thu, 26 Mar 2015 09:49:09 -0700 (PDT) Date: Thu, 26 Mar 2015 09:49:09 -0700 X-Google-Sender-Auth: NBilI4HWCXo7_zxpp8g-w81UsaE Message-ID: Subject: Unable to boot system over BOOTP From: Justin Hibbits To: FreeBSD PowerPC ML , freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:49:12 -0000 Bringing up a RouterBoard RB800, I'm trying to use the bootpd server that comes in base to netboot the board from another system. The kernel boots fine, but when it tries to mount the root, it attempts another DHCP/BOOTP request, and continuously times out. Has anyone else been able to get a machine to boot from BOOTP (not DHCP) using the base utilities? The configuration is as follows: /etc/bootptab: jumpgate:hn:ha=000c42aedcc6:bf=kernel.rb800:ip=10.0.0.2:rp="10.0.0.5:/zhabar/jails/rb800":vm=rfc1048:sa=10.0.0.5: Relevant logs: RouterBoard: ... bootpc_init: wired to interface 'tsec0' Sending DHCP Discover packet from interface tsec0 (00:0c:42:ae:dc:c6) tsec0: link state changed to DOWN tsec0: link state changed to UP DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 ... bootpd: bootpd: info(6): recvd pkt from IP addr 0.0.0.0 bootpd: info(6): bootptab mtime: Wed Mar 25 23:04:17 2015 bootpd: info(6): request from Ethernet address 00:0C:42:AE:DC:C6 bootpd: info(6): found 10.0.0.2 (jumpgate) bootpd: info(6): bootfile="/kernel.rb800" bootpd: info(6): vendor magic field is 99.130.83.99 bootpd: info(6): request message length=1460 bootpd: info(6): request has DHCP msglen=1460 bootpd: info(6): extended reply, length=1418, options=1182 bootpd: info(6): sending reply (with RFC1048 options) bootpd: info(6): setarp 10.0.0.2 - 00:0C:42:AE:DC:C6 Every request looks like that. I also ran tcpdump to check, and that looks fine. I'm using the stock MPC85XX kernel config with unrelated changes (additional devices, debugging, for other purposes). Thanks, Justin From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 26 17:07:34 2015 Return-Path: Delivered-To: freebsd-ppc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BD6086B for ; Thu, 26 Mar 2015 17:07:34 +0000 (UTC) Received: from montes3.cim.es (m225.cim.es [89.17.211.119]) (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 309F28EF for ; Thu, 26 Mar 2015 17:07:34 +0000 (UTC) Received: from proxy4.ayto-ciudadreal.es (aytoib4.ayto-ciudadreal.es [149.12.68.131]) by montes3.cim.es (8.14.9/8.13.5) with ESMTP id t2QH6muG000432 for ; Thu, 26 Mar 2015 18:06:49 +0100 Received: from TWMDM01 (60-249-226-209.HINET-IP.hinet.net [60.249.226.209]) (authenticated bits=0) by proxy4.ayto-ciudadreal.es (8.14.8/8.13.5) with ESMTP id t2QErYJU000812 for ; Thu, 26 Mar 2015 18:05:43 +0100 Message-Id: <201503261705.t2QErYJU000812@proxy4.ayto-ciudadreal.es> From: "Jorge Kiong" Subject: Thu 3/26/15 To: freebsd-ppc@FreeBSD.org MIME-Version: 1.0 Reply-To: j.kiong@aol.com Date: Fri, 27 Mar 2015 01:07:28 +0800 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:07:34 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Sir, I am the Head of Finance at Finance One Hong Kong Limited, a leading f= inancial and asset Management Company here in Hong Kong. I am in control of funds from a consortium of Private Investors for l= ong term investments. If you are in need of funds to expand existing businesses or to start = up a new project, then look no further as we would be more than deligh= ted to work with you. We are driven by a project's credibility to yield investment returns a= nd should we ascertain your project as such, we will engage our funds = at guaranteed 3% Fixed Interest Rate per annum but strictly in form of= Loans. Regards, Jorge Kiong Finance One Hong Kong Limited From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 02:42:45 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F42DC0C for ; Fri, 27 Mar 2015 02:42:45 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 DB7E819F for ; Fri, 27 Mar 2015 02:42:43 +0000 (UTC) Received: (qmail 15015 invoked from network); 27 Mar 2015 02:36:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 02:36:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 26 Mar 2015 22:36:03 -0400 (EDT) Received: (qmail 15043 invoked from network); 27 Mar 2015 02:36:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 02:36:03 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id C970C1C43A2; Thu, 26 Mar 2015 19:35:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598 Date: Thu, 26 Mar 2015 19:36:01 -0700 Message-Id: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> To: freebsd-current@freebsd.org, tuexen@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 02:42:45 -0000 Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. Both of the following = exist: /usr/src/sys/netinet/sctp.h /usr/include/netinet/sctp.h The first can be newer than the 2nd during buildworld. The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an = updated /usr/src can/does end up using the second instead of the first, = at least for the powerpc64-xtoolchain-gcc style of buildworld activity = that I am trying. The recent addition of SCTP_MAX_CWND ends up with its definition missing = because of this: during the build /usr/include/netinet/sctp.h ends up = being the file included and the compile fails from the missing = additional definition. Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the = command line arguments should force the /usr/src/sys/netinet/sctp.h = vintage file to be found. The 3 netinet/ relevant includes are shown = below... > ... > #include > #include > #include > #include More than sctp.h might have such issues since there are 3 netinet/ = include paths in /head/lib/libc/net/sctp_sys_calls.c . I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/lib/libc/net/sctp_sys_calls.c -r279859 added: > case SCTP_MAX_CWND: > ((struct sctp_assoc_value *)arg)->assoc_id =3D id; > break; and head (20150325 r280598) contains it. But the SCTP_MAX_CWND reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include = -I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE = -I/usr/src/lib/libc/../../contrib/gdtoa = -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 = -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE = -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd = -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION = -I/usr/src/lib/libc/../../contrib/tzcode/stdtime = -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES = -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING = -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=3Dgnu99 -fstack-protector = -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized = -Wno-pointer-sign -c /usr/src/lib/libc/net/sctp_sys_calls.c -o = sctp_sys_calls.So >=20 > /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info': > /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND' = undeclared (first use in this function) > case SCTP_MAX_CWND: ^ Looking to see where usage and definitions might be in /usr/src for = -r280598 ... > # pwd > /usr/src > $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = SCTP_MAX_CWND {} \; -print \) | more > case SCTP_MAX_CWND: > ./lib/libc/net/sctp_sys_calls.c > case SCTP_MAX_CWND: > case SCTP_MAX_CWND: > ./sys/netinet/sctp_usrreq.c > #define SCTP_MAX_CWND 0x00000032 > ./sys/netinet/sctp.h And looking at the list of includes in = /head/lib/libc/net/sctp_sys_calls.c for -r279859 shows: > #include > __FBSDID("$FreeBSD$"); >=20 > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include That there was no complaint about sctp.h being missing suggests that a = was found but did not contain a SCTP_MAX_CWND = definition: so a different one than the above find/grep reported. Using a find to report other sctp.h files shows: > # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h = -print \) | more > /usr/src/sys/netinet/sctp.h > /usr/include/netinet/sctp.h The diff of those shows the problem if the wrong file is found and used: > # diff /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h > 34c34 > < __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 = 15:50:16Z tuexen $"); > --- > > __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 = 19:49:25Z tuexen $"); > 130a131 > > #define SCTP_MAX_CWND 0x00000032 Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > 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 > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 04:15:51 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C4DB1FD for ; Fri, 27 Mar 2015 04:15:51 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 B4B6FD64 for ; Fri, 27 Mar 2015 04:15:50 +0000 (UTC) Received: (qmail 30757 invoked from network); 27 Mar 2015 04:15:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 04:15:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 27 Mar 2015 00:15:49 -0400 (EDT) Received: (qmail 28049 invoked from network); 27 Mar 2015 04:15:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 04:15:48 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id DC50A1C43A2; Thu, 26 Mar 2015 21:15:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs. updating to head snaphot -r280598 From: Mark Millard In-Reply-To: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> Date: Thu, 26 Mar 2015 21:15:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> To: freebsd-current@freebsd.org, Ian Lepore X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 04:15:51 -0000 Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. Both of the following = exist: /usr/src/sys/sys/sbuf.h /usr/include/sys/sbuf.h The first can be newer than the 2nd during buildworld. The buildworld compile of /head/sys/kern/subr_sbuf.c from an updated = /usr/src can/does end up using the second instead of the first, at least = for the powerpc64-xtoolchain-gcc style of buildworld activity that I am = trying. The recent addition of SBUF_INCLUDENUL use ends up with its definition = missing because of this: during the build /usr/include/sys/sbuf.h ends = up being the file included and the compile fails from the missing = additional definition. Either the #include paths in /head/sys/kern/subr_sbuf.c or the command = line arguments should force the /usr/src/sys/sys/sbuf.h vintage file to = be found. The /head/sys/kern/subr_sbuf.c relevant includes are shown = below... > #include > __FBSDID("$FreeBSD: head/sys/kern/subr_sbuf.c 280193 2015-03-17 = 21:00:31Z ian $"); >=20 > #include >=20 > #ifdef _KERNEL > #include > #include > #include > #include > #include > #include > #include > #else /* _KERNEL */ > #include > #include > #include > #include > #include > #include > #endif /* _KERNEL */ >=20 > #include I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/sys/kern/subr_sbuf.c -r280193 added: > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) and head (20150325 r280598) contains it. But the SBUF_INCLUDENUL reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-pro > totypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings = -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts = -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -c = /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c -o subr_sbuf.So > ... > /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c:73:45: error: = 'SBUF_INCLUDENUL' undeclared (first use in this function) > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) > ^ Looking to see where SBUF_INCLUDENUL usage and definitions might be in = /usr/src for -r280598 ... > # pwd > /usr/src > # find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = SBUF_INCLUDENUL {} \; -print \) | more > .It Dv SBUF_INCLUDENUL > ./share/man/man9/sbuf.9 > #define SBUF_INCLUDENUL 0x00000002 /* nulterm byte is counted in = len */ > ./sys/sys/sbuf.h > sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL); > ./sys/vm/uma_core.c > SBUF_INCLUDENUL); > ./sys/netinet/tcp_hostcache.c > sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL); > ./sys/kern/kern_malloc.c > SBUF_INCLUDENUL); > ./sys/kern/kern_cons.c > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > ./sys/kern/kern_descrip.c > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > ./sys/kern/kern_proc.c > sbuf_new(&sb, NULL, 256, SBUF_AUTOEXTEND | SBUF_INCLUDENUL); > ./sys/kern/kern_et.c > sbuf_new(&sb, NULL, 128, SBUF_AUTOEXTEND | SBUF_INCLUDENUL); > ./sys/kern/kern_fail.c > s =3D sbuf_new(s, buf, length, SBUF_FIXEDLEN | = SBUF_INCLUDENUL); > ./sys/kern/kern_sysctl.c > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) > ./sys/kern/subr_sbuf.c Looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c = for -r280193 shows: > #include > __FBSDID("$FreeBSD: head/sys/kern/subr_sbuf.c 280193 2015-03-17 = 21:00:31Z ian $"); >=20 > #include >=20 > #ifdef _KERNEL > #include > #include > #include > #include > #include > #include > #include > #else /* _KERNEL */ > #include > #include > #include > #include > #include > #include > #endif /* _KERNEL */ >=20 > #include That there was no complaint about sbuf.h being missing suggests that a = was found but did not contain a SBUF_INCLUDENUL definition: = so a different one than the above find/grep reported. Using a find to report other sctp.h files shows: > # find /usr/include \( -type d -name .svn -prune \) -or \( -type f = -name sbuf.h -print \) | more > /usr/include/sys/sbuf.h The diff of the two variants shows the problem if the wrong file is = found and used: > # diff /usr/include/sys/sbuf.h /usr/src/sys/sys/sbuf.h > 28c28 > < * $FreeBSD: head/sys/sys/sbuf.h 269179 2014-07-28 07:20:22Z = gahr $ > --- > > * $FreeBSD: head/sys/sys/sbuf.h 279992 2015-03-14 16:02:11Z = ian $ > 50a51 > > #define SBUF_INCLUDENUL 0x00000002 /* nulterm byte is = counted in len */ > 66a68,70 > > int sbuf_get_flags(struct sbuf *); > > void sbuf_clear_flags(struct sbuf *, int); > > void sbuf_set_flags(struct sbuf *, int); Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > 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 > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 09:44:06 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E03F9337 for ; Fri, 27 Mar 2015 09:44:06 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 9556F26E for ; Fri, 27 Mar 2015 09:44:05 +0000 (UTC) Received: (qmail 27871 invoked from network); 27 Mar 2015 09:44:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 09:44:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 27 Mar 2015 05:44:04 -0400 (EDT) Received: (qmail 26898 invoked from network); 27 Mar 2015 09:44:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 09:44:04 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A51AE1C43A8; Fri, 27 Mar 2015 02:44:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: 11.0-CURRENT: BIO_F_DGRAM_SCTP_WRITE, /head/crypto/openssl/crypto/bio/bio_err.c -r280297 vs. updating to head snaphot -r280598 From: Mark Millard In-Reply-To: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> Date: Fri, 27 Mar 2015 02:44:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2B8572-425D-42EC-AD9D-8975E9B9CBFA@dsl-only.net> References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> To: freebsd-current@freebsd.org, jkim@FreeBSD.org X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 09:44:07 -0000 Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. All of the following = exist: > /usr/src/crypto/openssl/crypto/bio/bio.h > /usr/obj/usr/src/tmp/usr/include/openssl/bio.h > /usr/include/openssl/bio.h The first two can be newer than the last during buildworld. The buildworld compile of /head/crypto/openssl/crypto/bio/bio_err.c from = an updated /usr/src can/does end up using the last instead of one of the = first two, at least for the powerpc64-xtoolchain-gcc style of buildworld = activity that I am trying. The recent addition of BIO_F_DGRAM_SCTP_WRITE ends up with its = definition missing because of this: during the build = /usr/include/openssl/bio.h ends up being the file included and the = compile fails from the missing additional definition. Either the #include paths in /head/crypto/openssl/crypto/bio/bio_err.c = or the command line arguments should force the = /usr/obj/usr/src/tmp/usr/include/openssl/bio.h (or = /usr/src/crypto/openssl/crypto/bio/bio.h ) vintage file to be found. The = bio.h relevant includes are shown below... > #include > #include > #include More than bio.h might have such issues since there is an openssl/err.h = include path in /head/crypto/openssl/crypto/bio/bio_err.c . I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/crypto/openssl/crypto/bio/bio_err.c -r280297 added: > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, and head (20150325 r280598) contains it. But the BIO_F_DGRAM_SCTP_WRITE reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -DTERMIOS -DANSI_SOURCE = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto = -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN = -DHAVE_DLFCN_H = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes = -std=3Dgnu89 -fstack-protector -Wno-pointer-sign -c = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= -o bio_err.So > In file included from = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= :63:0: > = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= :99:15: error: 'BIO_F_DGRAM_SCTP_WRITE' undeclared here (not in a = function) > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, > ^ Looking to see where usage and definitions might be in /usr/src for = -r280598 ... > # pwd > /usr/src > $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = BIO_F_DGRAM_SCTP_WRITE {} \; -print \) | more > # define BIO_F_DGRAM_SCTP_WRITE 133 > ./crypto/openssl/crypto/bio/bio.h > BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_ERROR); > ./crypto/openssl/crypto/bio/bss_dgram.c > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, > ./crypto/openssl/crypto/bio/bio_err.c And looking at the list of includes in = /head/crypto/openssl/crypto/bio/bio_err.c -r280297 shows: > #include > #include > #include That there was no complaint about bio.h being missing suggests that a = was found but did not contain a BIO_F_DGRAM_SCTP_WRITE = definition: so a different one than a copy of what the above find/grep = reported. Using a find to report other bio.h files shows: > # find / \( -type d -name .svn -prune \) -or \( -type f -name bio.h = -print \) | more > /usr/src/crypto/openssl/crypto/bio/bio.h > /usr/src/sys/sys/bio.h > /usr/obj/usr/src/tmp/usr/include/openssl/bio.h > /usr/include/openssl/bio.h > /usr/include/sys/bio.h (Ignoring .../sys/bio.h as distinct by content and by path prefix...) The diff of /usr/obj/usr/src/tmp/usr/include/openssl/bio.h and = /usr/include/openssl/bio.h shows the problem if the wrong file is found = and used: > diff -w /usr/src/crypto/openssl/crypto/bio/bio.h = /usr/include/openssl/bio.h | less > ... > 797,798c775 > < /* > < * The following lines are auto generated by the script mkerr.pl. = Any changes > --- > > /* The following lines are auto generated by the script mkerr.pl. = Any changes > 832d808 > < # define BIO_F_DGRAM_SCTP_WRITE 133 Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > 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 > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 12:50:41 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3060EAA for ; Fri, 27 Mar 2015 12:50:40 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (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 9628CDA9 for ; Fri, 27 Mar 2015 12:50:39 +0000 (UTC) Received: (qmail 32161 invoked from network); 27 Mar 2015 12:50:33 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 12:50:33 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 27 Mar 2015 08:50:33 -0400 (EDT) Received: (qmail 14414 invoked from network); 27 Mar 2015 12:50:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 12:50:33 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id C1E9F1C43B2; Fri, 27 Mar 2015 05:50:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: 11.0-CURRENT: DTLS1_VERSION_MAJOR, /head/crypto/openssl/ssl/ssl_asn1.c -r280297 vs. updating to head snaphot -r280598 From: Mark Millard In-Reply-To: <2D2B8572-425D-42EC-AD9D-8975E9B9CBFA@dsl-only.net> Date: Fri, 27 Mar 2015 05:50:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> <2D2B8572-425D-42EC-AD9D-8975E9B9CBFA@dsl-only.net> To: freebsd-current@freebsd.org, jkim@FreeBSD.org X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:50:41 -0000 /head/crypto/openssl/ssl/ssl_asn1.c has a similar issue to = /head/crypto/openssl/crypto/bio/bio_err.c but relative to: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -DTERMIOS -DANSI_SOURCE = -I/usr/src/secure/lib/libssl/../../../crypto/openssl = -I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto = -I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN = -DHAVE_DLFCN_H -std=3Dgnu99 -fstack-protector -Wno-pointer-sign -c = /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_asn1.c -o = ssl_asn1.So > /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_asn1.c: In = function 'd2i_SSL_SESSION': > = /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_asn1.c:425:34: = error: 'DTLS1_VERSION_MAJOR' undeclared (first use in this function) > || (ssl_version >> 8) =3D=3D DTLS1_VERSION_MAJOR > ^ > # pwd > /usr/src > # find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = DTLS1_VERSION_MAJOR {} \; -print \) | more > # define DTLS1_VERSION_MAJOR 0xFE > ./crypto/openssl/ssl/dtls1.h > || (ssl_version >> 8) =3D=3D DTLS1_VERSION_MAJOR > ./crypto/openssl/ssl/ssl_asn1.c > # find / \( -type d -name .svn -prune \) -or \( -type f -name dtls1.h = -print \) | more > /usr/src/crypto/openssl/ssl/dtls1.h > /usr/obj/usr/src/tmp/usr/include/openssl/dtls1.h > /usr/include/openssl/dtls1.h > #include > #include > #include "ssl_locl.h" > #include > #include > #include So the crypto/openssl/ssl/dtls1.h or = /usr/obj/usr/src/tmp/usr/include/openssl/dtls1.h file is not directly = included at all. Finding where it is included... Omitting most Makefile lines... > # find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = "dtls1\.h" {} \; -print \) | more > INCS=3D dtls1.h kssl.h srtp.h ssl.h ssl2.h ssl23.h ssl3.h tls1.h > ./secure/lib/libssl/Makefile > ... > ./crypto/openssl/apps/Makefile > /* ssl/dtls1.h */ > ./crypto/openssl/ssl/dtls1.h > ... > ./crypto/openssl/ssl/Makefile > # include /* Datagram TLS */ > ./crypto/openssl/ssl/ssl.h crypto/openssl/ssl/ssl.h is not directly included. (I will stop here as = far as the include sequence goes since a dtls1.h was found.) The reference is finding /usr/include/openssl/dtls1.h = (old) instead of /usr/obj/usr/src/tmp/usr/include/openssl/dtls1.h or = /usr/src/crypto/openssl/ssl/dtls1.h (new): > # diff -w /usr/include/openssl/dtls1.h = /usr/obj/usr/src/tmp/usr/include/openssl/dtls1.h | more > 87a88 > > # define DTLS1_VERSION_MAJOR 0xFE > 123,129c124,128 > ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-27, at 02:44 AM, Mark Millard = wrote: Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. All of the following = exist: > /usr/src/crypto/openssl/crypto/bio/bio.h > /usr/obj/usr/src/tmp/usr/include/openssl/bio.h > /usr/include/openssl/bio.h The first two can be newer than the last during buildworld. The buildworld compile of /head/crypto/openssl/crypto/bio/bio_err.c from = an updated /usr/src can/does end up using the last instead of one of the = first two, at least for the powerpc64-xtoolchain-gcc style of buildworld = activity that I am trying. The recent addition of BIO_F_DGRAM_SCTP_WRITE ends up with its = definition missing because of this: during the build = /usr/include/openssl/bio.h ends up being the file included and the = compile fails from the missing additional definition. Either the #include paths in /head/crypto/openssl/crypto/bio/bio_err.c = or the command line arguments should force the = /usr/obj/usr/src/tmp/usr/include/openssl/bio.h (or = /usr/src/crypto/openssl/crypto/bio/bio.h ) vintage file to be found. The = bio.h relevant includes are shown below... > #include > #include > #include More than bio.h might have such issues since there is an openssl/err.h = include path in /head/crypto/openssl/crypto/bio/bio_err.c . I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/crypto/openssl/crypto/bio/bio_err.c -r280297 added: > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, and head (20150325 r280598) contains it. But the BIO_F_DGRAM_SCTP_WRITE reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -DTERMIOS -DANSI_SOURCE = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto = -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN = -DHAVE_DLFCN_H = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp = -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes = -std=3Dgnu89 -fstack-protector -Wno-pointer-sign -c = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= -o bio_err.So > In file included from = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= :63:0: > = /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bio_err.c= :99:15: error: 'BIO_F_DGRAM_SCTP_WRITE' undeclared here (not in a = function) > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, > ^ Looking to see where usage and definitions might be in /usr/src for = -r280598 ... > # pwd > /usr/src > $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = BIO_F_DGRAM_SCTP_WRITE {} \; -print \) | more > # define BIO_F_DGRAM_SCTP_WRITE 133 > ./crypto/openssl/crypto/bio/bio.h > BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_ERROR); > ./crypto/openssl/crypto/bio/bss_dgram.c > {ERR_FUNC(BIO_F_DGRAM_SCTP_WRITE), "DGRAM_SCTP_WRITE"}, > ./crypto/openssl/crypto/bio/bio_err.c And looking at the list of includes in = /head/crypto/openssl/crypto/bio/bio_err.c -r280297 shows: > #include > #include > #include That there was no complaint about bio.h being missing suggests that a = was found but did not contain a BIO_F_DGRAM_SCTP_WRITE = definition: so a different one than a copy of what the above find/grep = reported. Using a find to report other bio.h files shows: > # find / \( -type d -name .svn -prune \) -or \( -type f -name bio.h = -print \) | more > /usr/src/crypto/openssl/crypto/bio/bio.h > /usr/src/sys/sys/bio.h > /usr/obj/usr/src/tmp/usr/include/openssl/bio.h > /usr/include/openssl/bio.h > /usr/include/sys/bio.h (Ignoring .../sys/bio.h as distinct by content and by path prefix...) The diff of /usr/obj/usr/src/tmp/usr/include/openssl/bio.h and = /usr/include/openssl/bio.h shows the problem if the wrong file is found = and used: > diff -w /usr/src/crypto/openssl/crypto/bio/bio.h = /usr/include/openssl/bio.h | less > ... > 797,798c775 > < /* > < * The following lines are auto generated by the script mkerr.pl. = Any changes > --- >> /* The following lines are auto generated by the script mkerr.pl. Any = changes > 832d808 > < # define BIO_F_DGRAM_SCTP_WRITE 133 Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > 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 > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 15:17:55 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E91A974F; Fri, 27 Mar 2015 15:17:55 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 76FA124C; Fri, 27 Mar 2015 15:17:55 +0000 (UTC) Received: from [IPv6:2001:67c:370:152:789e:cdca:2174:5587] (unknown [IPv6:2001:67c:370:152:789e:cdca:2174:5587]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A50491C1622C1; Fri, 27 Mar 2015 16:17:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598 From: Michael Tuexen In-Reply-To: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> Date: Fri, 27 Mar 2015 10:17:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-current@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 15:17:56 -0000 > On 26 Mar 2015, at 21:36, Mark Millard wrote: >=20 > Basic context: >=20 > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 >=20 >=20 > The problem: >=20 > Summary of the details that are listed later. Both of the following = exist: >=20 > /usr/src/sys/netinet/sctp.h > /usr/include/netinet/sctp.h >=20 > The first can be newer than the 2nd during buildworld. >=20 > The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an = updated /usr/src can/does end up using the second instead of the first, = at least for the powerpc64-xtoolchain-gcc style of buildworld activity = that I am trying. >=20 > The recent addition of SCTP_MAX_CWND ends up with its definition = missing because of this: during the build /usr/include/netinet/sctp.h = ends up being the file included and the compile fails from the missing = additional definition. >=20 > Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or = the command line arguments should force the /usr/src/sys/netinet/sctp.h = vintage file to be found. The 3 netinet/ relevant includes are shown = below... >=20 >> ... >> #include >> #include >> #include >> #include >=20 > More than sctp.h might have such issues since there are 3 netinet/ = include paths in /head/lib/libc/net/sctp_sys_calls.c . >=20 > I have not checked for other .c files with similar issues for = usage during buildworld. I guess there is something wrong with the build system / Makefiles such = that the entries in the search path for include files are in the wrong order. I don't think this is = related to the concrete patch you are referring to. It only exposes the problem. As I see, you = experience similar problems in other situations to. Maybe someone knowing the build system has to look into it. And it seems = to be somewhat platform specific, since I have not observed this problem when testing the build on amd64 = and arm. Best regards Michael >=20 >=20 > The problem details: >=20 > /head/lib/libc/net/sctp_sys_calls.c -r279859 added: >=20 >> case SCTP_MAX_CWND: >> ((struct sctp_assoc_value *)arg)->assoc_id =3D id; >> break; >=20 > and head (20150325 r280598) contains it. >=20 > But the SCTP_MAX_CWND reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): >=20 >> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include = -I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE = -I/usr/src/lib/libc/../../contrib/gdtoa = -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 = -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE = -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd = -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION = -I/usr/src/lib/libc/../../contrib/tzcode/stdtime = -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES = -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING = -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=3Dgnu99 -fstack-protector = -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized = -Wno-pointer-sign -c /usr/src/lib/libc/net/sctp_sys_calls.c -o = sctp_sys_calls.So >>=20 >> /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info': >> /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND' = undeclared (first use in this function) >> case SCTP_MAX_CWND: > ^ > Looking to see where usage and definitions might be in /usr/src for = -r280598 ... >=20 >> # pwd >> /usr/src >> $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = SCTP_MAX_CWND {} \; -print \) | more >> case SCTP_MAX_CWND: >> ./lib/libc/net/sctp_sys_calls.c >> case SCTP_MAX_CWND: >> case SCTP_MAX_CWND: >> ./sys/netinet/sctp_usrreq.c >> #define SCTP_MAX_CWND 0x00000032 >> ./sys/netinet/sctp.h >=20 > And looking at the list of includes in = /head/lib/libc/net/sctp_sys_calls.c for -r279859 shows: >=20 >> #include >> __FBSDID("$FreeBSD$"); >>=20 >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >=20 > That there was no complaint about sctp.h being missing suggests that a = was found but did not contain a SCTP_MAX_CWND = definition: so a different one than the above find/grep reported. >=20 > Using a find to report other sctp.h files shows: >=20 >> # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h = -print \) | more >> /usr/src/sys/netinet/sctp.h >> /usr/include/netinet/sctp.h >=20 > The diff of those shows the problem if the wrong file is found and = used: >=20 >> # diff /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h >> 34c34 >> < __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 = 15:50:16Z tuexen $"); >> --- >>> __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 = 19:49:25Z tuexen $"); >> 130a131 >>> #define SCTP_MAX_CWND 0x00000032 >=20 >=20 >=20 >=20 > Context details: >=20 >> make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 >> WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ >> WITHOUT_LLDB=3D \ >> WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ >> WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ >> buildworld buildkernel \ >> KERNCONF=3DGENERIC64vtsc-NODEBUG >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 >=20 >> # svnlite info /usr/src >> Path: . >> Working Copy Root Path: /usr/src >> URL: https://svn0.us-west.freebsd.org/base/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 280615 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: hselasky >> Last Changed Rev: 280598 >> Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) >=20 > signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. >=20 >> # svnlite st /usr/src --no-ignore >> ? /usr/src/.snap >> ? /usr/src/restoresymtable >> M /usr/src/sys/ddb/db_main.c >> M /usr/src/sys/ddb/db_script.c >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/ofw/ofwcall64.S >=20 > (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) >=20 >> # more /etc/src.conf=20 >> NO_WERROR=3D >> WITH_LIBCPLUSPLUS=3D >> 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 >> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11= -L/usr/obj/usr/srcC/lib/libc++/. >> CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. >=20 > (The above and just below experiments with mostly(?) avoiding use of = gcc 4.2.1, even for CC/CXX/CPP contexts.) >=20 >> # ls -FPal /usr/bin/g[+c]* >> lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ >> lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >=20 >> # more /etc/make.conf >> WRKDIRPREFIX=3D/usr/obj/portswork >> #WITH_DEBUG=3D >> MALLOC_PRODUCTION=3D >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 27 15:32:40 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25773C2B; Fri, 27 Mar 2015 15:32:40 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i207.relay.mailchannels.net [162.253.144.89]) by mx1.freebsd.org (Postfix) with ESMTP id DB910633; Fri, 27 Mar 2015 15:32:37 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 2E9CB10119A; Fri, 27 Mar 2015 15:32:30 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Fri, 27 Mar 2015 15:32:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1427470350342:4015143094 X-MC-Ingress-Time: 1427470350342 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YbWFC-0000AY-TW; Fri, 27 Mar 2015 15:32:23 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2RFWE84050067; Fri, 27 Mar 2015 09:32:14 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/p1dBeDX9zDoL90mYtO9pt Message-ID: <1427470334.91374.4.camel@freebsd.org> Subject: Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598 From: Ian Lepore To: Michael Tuexen Date: Fri, 27 Mar 2015 09:32:14 -0600 In-Reply-To: References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-current@freebsd.org, FreeBSD PowerPC ML , Mark Millard X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 15:32:40 -0000 On Fri, 2015-03-27 at 10:17 -0500, Michael Tuexen wrote: > > On 26 Mar 2015, at 21:36, Mark Millard wrote: > > > > Basic context: > > > > # freebsd-version -ku; uname -apKU > > 11.0-CURRENT > > 11.0-CURRENT > > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 1100062 1100062 > > > > > > The problem: > > > > Summary of the details that are listed later. Both of the following exist: > > > > /usr/src/sys/netinet/sctp.h > > /usr/include/netinet/sctp.h > > > > The first can be newer than the 2nd during buildworld. > > > > The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an updated /usr/src can/does end up using the second instead of the first, at least for the powerpc64-xtoolchain-gcc style of buildworld activity that I am trying. > > > > The recent addition of SCTP_MAX_CWND ends up with its definition missing because of this: during the build /usr/include/netinet/sctp.h ends up being the file included and the compile fails from the missing additional definition. > > > > Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the command line arguments should force the /usr/src/sys/netinet/sctp.h vintage file to be found. The 3 netinet/ relevant includes are shown below... > > > >> ... > >> #include > >> #include > >> #include > >> #include > > > > More than sctp.h might have such issues since there are 3 netinet/ include paths in /head/lib/libc/net/sctp_sys_calls.c . > > > > I have not checked for other .c files with similar issues for usage during buildworld. > I guess there is something wrong with the build system / Makefiles such that the entries in the search > path for include files are in the wrong order. I don't think this is related to the concrete patch > you are referring to. It only exposes the problem. As I see, you experience similar problems in > other situations to. > > Maybe someone knowing the build system has to look into it. And it seems to be somewhat platform specific, > since I have not observed this problem when testing the build on amd64 and arm. > > Best regards > Michael This and the other similar reports on current@ appear to be problems with the xtoolchain ports, not the base build system, and probably should have been reported to the port's maintainer, or on ports@. Or perhaps it's some sort of usage error, I don't know anything about the xtoolchain stuff. In any case, there doesn't seem to be anything wrong with the base build using the supported build mechanisms. -- Ian