From owner-freebsd-ppc@FreeBSD.ORG Mon Apr 6 13:39: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 DF94DA09 for ; Mon, 6 Apr 2015 13:39:56 +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 9982A98B for ; Mon, 6 Apr 2015 13:39:56 +0000 (UTC) Received: (qmail 18449 invoked from network); 6 Apr 2015 13:39:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Apr 2015 13:39:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 06 Apr 2015 09:39:48 -0400 (EDT) Received: (qmail 15130 invoked from network); 6 Apr 2015 13:39:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Apr 2015 13:39:48 -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 3697C1C43C4; Mon, 6 Apr 2015 06:39:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FYI: Some problems with powerpc (non-64) 11.0-CURRENT -r280867: sendmail stack corruption; PRNG not seeded Date: Mon, 6 Apr 2015 06:39:46 -0700 Message-Id: <3C815370-6DAF-42C7-9CC5-2334F07C9E60@dsl-only.net> To: Nathan Whitehorn 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: Mon, 06 Apr 2015 13:39:57 -0000 In my exploring of FreeBSD 11.0-CURRENT on PowerMac's I've noted before = that modern vintages of the powerpc (non-64) do not boot the G5's or the = iMac 3 that I have access to but do boot the G4s that historically = worked. But I've noticed a couple of things that are note working right for the = G4's. I do not know what to attribute them to, unfortunately. Still for = (A) below I've got the evidence about where the segmentation fault is = happening in sendmail. I report on -r280867 specifically just because I've used it a lot more = than somewhat older variants that I'd built before. I doubt that the = issues are unique to -r280867. A) /usr/libexec/sendmail/sendmail is leaving .core files in /var/crash/ = periodically. (Details later below.) B) The attempt to start sshd before login reports that "PRNG is not = seeded". (Details later below.) Basic context: > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG3C0 11.0-CURRENT FreeBSD 11.0-CURRENT #8 r280867M: Mon = Apr 6 02:12:28 PDT 2015 = root@FBSDG5S1:/usr/obj/powerpc.powerpc/usr/srcC/sys/GENERICvtsc-NODEBUG = powerpc powerpc 1100067 1100067 (A few files have to have more recent versions in order to build what is = generally -r280867.) This is a gcc 4.2.1 based build. A) /usr/libexec/sendmail/sendmail is leaving .core files in /var/crash/ = periodically (segmentation fault). (I only have the automatic/default sendmail activity: I never turned it = off but do not use it on the PowerMac's.) As I understand the following: It gets the segmentation fault from r29=3D0= during the code sequence for checking the stack (so the bl to = __stack_chk_fail@plt is not reached). > # gdb /usr/libexec/sendmail/sendmail /var/crash/sendmail.728.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc-marcel-freebsd"... > Core was generated by `sendmail'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libutil.so.9...Reading symbols from = /usr/lib/debug//lib/libutil.so.9.debug...done. > done. > Loaded symbols for /lib/libutil.so.9 > Reading symbols from /usr/lib/libwrap.so.6...Reading symbols from = /usr/lib/debug//usr/lib/libwrap.so.6.debug...done. > done. > Loaded symbols for /usr/lib/libwrap.so.6 > Reading symbols from /usr/lib/libssl.so.7...Reading symbols from = /usr/lib/debug//usr/lib/libssl.so.7.debug...done. > done. > Loaded symbols for /usr/lib/libssl.so.7 > Reading symbols from /lib/libcrypto.so.7...Reading symbols from = /usr/lib/debug//lib/libcrypto.so.7.debug...done. > done. > Loaded symbols for /lib/libcrypto.so.7 > Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. > done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. > done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > done. > Loaded symbols for /libexec/ld-elf.so.1 > (gdb) bt > #0 0x4191cac0 in hosts_ctl (daemon=3D, = name=3D, addr=3D, user=3D) > at /usr/srcC/lib/libwrap/../../contrib/tcp_wrappers/hosts_ctl.c:38 > #1 0x4191cabc in hosts_ctl (daemon=3D, = name=3D, addr=3D, user=3D) > at /usr/srcC/lib/libwrap/../../contrib/tcp_wrappers/hosts_ctl.c:32 > #2 0x018322f8 in main (argc=3D6, argv=3D0x6f776e00, envp=3D) at = /usr/srcC/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:2649 > #3 0x01804a24 in _start () > #4 0x418c0fa0 in .text () at = /usr/srcC/libexec/rtld-elf/powerpc/rtld_start.S:112 > (gdb) x/64i 0x4191ca40 > 0x4191ca40 : lwz r0,0(r3) > 0x4191ca44 : mr r3,r29 > 0x4191ca48 : rlwinm r0,r0,2,0,29 > 0x4191ca4c : lwzx r4,r25,r0 > 0x4191ca50 : bl 0x41931890 > 0x4191ca54 : b 0x4191ca10 > 0x4191ca58 : stwu r1,-864(r1) > 0x4191ca5c : mflr r0 > 0x4191ca60 : bl 0x41931594 <.got+548> > 0x4191ca64 : mr r9,r5 > 0x4191ca68 : stw r30,856(r1) > 0x4191ca6c : mflr r30 > 0x4191ca70 : stw r6,8(r1) > 0x4191ca74 : mr r7,r4 > 0x4191ca78 : stw r29,852(r1) > 0x4191ca7c : mr r5,r3 > 0x4191ca80 : stw r0,868(r1) > 0x4191ca84 : li r4,2 > 0x4191ca88 : lwz r29,-36(r30) > 0x4191ca8c : li r6,4 > 0x4191ca90 : li r8,5 > 0x4191ca94 : li r10,3 > 0x4191ca98 : lwz r0,0(r29) > 0x4191ca9c : stw r0,844(r1) > 0x4191caa0 : li r0,0 > 0x4191caa4 : addi r3,r1,16 > 0x4191caa8 : stw r0,12(r1) > 0x4191caac : crclr 4*cr1+eq > 0x4191cab0 : bl 0x41931870 > 0x4191cab4 : crclr 4*cr1+eq > 0x4191cab8 : bl 0x419317b0 > 0x4191cabc : lwz r0,844(r1) > 0x4191cac0 : lwz r9,0(r29) > 0x4191cac4 : xor. r0,r0,r9 > 0x4191cac8 : li r9,0 > 0x4191cacc : bne- 0x4191cae8 > 0x4191cad0 : lwz r0,868(r1) > 0x4191cad4 : lwz r29,852(r1) > 0x4191cad8 : lwz r30,856(r1) > 0x4191cadc : mtlr r0 > 0x4191cae0 : addi r1,r1,864 > 0x4191cae4 : blr > 0x4191cae8 : bl 0x41931810 = <__stack_chk_fail@plt> > 0x4191caec : stwu r1,-896(r1) > 0x4191caf0 : mflr r0 > 0x4191caf4 : bl 0x41931594 <.got+548> > 0x4191caf8 : li r9,128 > 0x4191cafc : stw r30,888(r1) > 0x4191cb00 : mflr r30 > 0x4191cb04 : stw r0,900(r1) > 0x4191cb08 : addi r4,r1,712 > 0x4191cb0c : stw r25,868(r1) > 0x4191cb10 : addi r5,r1,20 > 0x4191cb14 : stw r27,876(r1) > 0x4191cb18 : lwz r25,-36(r30) > 0x4191cb1c : lwz r27,0(r3) > 0x4191cb20 : stw r28,880(r1) > 0x4191cb24 : lwz r0,0(r25) > 0x4191cb28 : stw r0,844(r1) > 0x4191cb2c : li r0,0 > 0x4191cb30 : mr r28,r3 > 0x4191cb34 : stw r23,860(r1) > (gdb) info registers > r0 0xb3a7e38 188382776 > r1 0xffffbb40 -17600 > r2 0x418e4708 1099843336 > r3 0x1 1 > r4 0x41932264 1100161636 > r5 0x0 0 > r6 0x1 1 > r7 0x61 97 > r8 0x0 0 > r9 0x418e4708 1099843336 > r10 0xffffbb20 -17632 > r11 0x4191ed60 1100082528 > r12 0x44000048 1140850760 > r13 0x0 0 > r14 0x6 6 > r15 0x0 0 > r16 0x0 0 > r17 0x1 1 > r18 0x0 0 > r19 0x0 0 > r20 0x18c703c 25980988 > r21 0xffffffff -1 > r22 0x18f2984 26159492 > r23 0x0 0 > r24 0x0 0 > r25 0x1 1 > r26 0x1896608 25781768 > r27 0x0 0 > r28 0x0 0 > r29 0x0 0 > r30 0x41931598 1100158360 > r31 0x0 0 > pc 0x4191cac0 1100073664 > ps 0x0 0 > cr 0x44000048 1140850760 > lr 0x4191cabc 1100073660 > ctr 0x41bd1ad0 1102912208 > xer 0x20000000 536870912 > fpscr 0x0 0 > vscr 0x0 0 > vrsave 0x0 0 My powerpc64 -r280867 build does not have this problem. (But it is a = powerpc64-xtoolchain-gcc based build. I should probably also build and = keep a normal gcc 4.2.1 one at some point.) I listed the above issue first because I had far more detailed/specific = evidence than the below. B) The attempt to start sshd before login reports: > Performing sanity check on sshd configuration. > PRNG is not seeded > /etc/rc: WARNING: failed precmd routine for sshd A "sshd -T" or other such command also reports "PRNG is not seeded". Looking at sysctl output... > kern.random.harvest.mask_symbolic: = UMA_ALLOC,SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CAC= HED > kern.random.harvest.mask_bin: 1111111111 > kern.random.harvest.mask: 1023 > kern.random.yarrow.slowoverthresh: 2 > kern.random.yarrow.slowthresh: 128 > kern.random.yarrow.fastthresh: 96 > kern.random.yarrow.bins: 10 > kern.random.yarrow.gengateinterval: 10 > kern.random.live_entropy_sources:=20 > kern.random.active_adaptor: yarrow > kern.random.adaptors: yarrow(90),dummy(1) does not seem odd to me for 11.0-CURRENT or in comparison to my = powerpc64 build's output. As for what all is non-default for my configuration files (not much)... My use of networking is minimal and the configuration changes for that = are limited to rc.conf: > # more /etc/rc.conf > hostname=3D"FBSDG5C0" > ifconfig_bge0=3D"DHCP" > ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" > ifconfig_gem0=3D"DHCP" > ifconfig_gem0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > #ntpd_enable=3D"YES" > #ntpd_sync_on_start=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > hald_enable=3D"YES" > dbus_enable=3D"YES" I also fiddle with /boot/loader.conf, /etc/fstab, /etc/make.conf, and = /etc/src.conf primarily. /etc/sysctl.conf for dump issues. = /usr/local/etc/sudoers . The rest of the configuration files are at the default/installation = status. My powerpc64 -r280867 build does not have this issue. (But it is a = powerpc64-xtoolchain-gcc based build.) Context details: # svnlite st /usr/srcC/ --no-ignore ? /usr/srcC/.snap ? /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 These are long standing changes associated with my finding a way for = PowerMac G5's to boot reliably (ofw_machdep.c) and getting some evidence = from early boot crashes in case they happen. Also the GENERIC*'s disable = ps3 in order to enable both vt and sc. They do include the standard = GENERIC*'s. Used for building the plain powerpc 11.0-CURRENT -r280867 variant that = produced the backtrace above: # more /etc/src.conf=20 #CFLAGS+=3D-DELF_VERBOSE WITH_DEBUG=3D WITH_DEBUG_FILES=3D # more /etc/make.conf=20 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 Apr 10 02:40:04 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 BE83C52E for ; Fri, 10 Apr 2015 02:40:04 +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 62AC7287 for ; Fri, 10 Apr 2015 02:40:03 +0000 (UTC) Received: (qmail 30225 invoked from network); 10 Apr 2015 02:40:02 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 02:40:02 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 22:40:02 -0400 (EDT) Received: (qmail 24503 invoked from network); 10 Apr 2015 02:40:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 02:40:01 -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 906971C4052; Thu, 9 Apr 2015 19:39:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> Date: Thu, 9 Apr 2015 19:40:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2098) 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, 10 Apr 2015 02:40:04 -0000 I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Apr-9, at 06:56 PM, Mark Millard wrote: =46rom share/mk/bsd.README : LDFLAGS Additional loader flags. Passed to the loader via CC, since that's used to link programs as well, so loader specific flags need to be prefixed with -Wl, to work. But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc In fact I get errors such as (for that last one when using powerpc64-gcc = via powerpc64-xtoolchain-gcc, executed on a powerpc64): > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that -Wl,-m,elf32pcc_fbsd is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc (This note is shorter in part because figured out more context than I = had last time.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 02:48:13 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 D680A6E3 for ; Fri, 10 Apr 2015 02:48:13 +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 7B4C5394 for ; Fri, 10 Apr 2015 02:48:13 +0000 (UTC) Received: (qmail 6679 invoked from network); 10 Apr 2015 02:48:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 02:48:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 22:48:12 -0400 (EDT) Received: (qmail 1897 invoked from network); 10 Apr 2015 02:48:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 02:48:11 -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 90E151C4052; Thu, 9 Apr 2015 19:48:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: Date: Thu, 9 Apr 2015 19:48:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@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, 10 Apr 2015 02:48:14 -0000 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 03:46:52 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 3BC1BEE4 for ; Fri, 10 Apr 2015 03:46:52 +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 E4FFDC82 for ; Fri, 10 Apr 2015 03:46:51 +0000 (UTC) Received: (qmail 2187 invoked from network); 10 Apr 2015 03:46:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 03:46:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 23:46:50 -0400 (EDT) Received: (qmail 32291 invoked from network); 10 Apr 2015 03:46:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 03:46:49 -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 204641C4052; Thu, 9 Apr 2015 20:46:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> Date: Thu, 9 Apr 2015 20:46:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@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, 10 Apr 2015 03:46:52 -0000 I had written: > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now based = on the notation -Wl,-m -Wl,elf32ppc_fbsd which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc = and the other is building 10.1-STABLE -r281235 via the system/normal gcc = 4.2.1. As my builds take considerable time if they actually complete, it will = be a while before I can try any other variations, such as trying a gcc = 4.2.1 cross-build for powerpc. Unfortunately for the purpose at hand: I=E2=80=99m not set up to test = any tier 1 FreeBSD environments at this time. So, for example, I can not = report observations for amd64 building elf_i386_fbsd materials. My tests = may be useful but are not sufficient of themselves to justify edits that = anyone worries might damage tier 1 build-ability. The places I found with notation to adjust if in general the updated = notation works are: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc and the tier 1 case using elf_i386_fbsd: > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference=E2=80=A6 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 04:40:15 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 A9ED76E0 for ; Fri, 10 Apr 2015 04:40:15 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (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 74854179 for ; Fri, 10 Apr 2015 04:40:15 +0000 (UTC) Received: by pdea3 with SMTP id a3so10251134pde.3 for ; Thu, 09 Apr 2015 21:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=kAM0sCXjUVOdGgLwZamN3s6M2ANFZIzJfdfuk5tJA0A=; b=QcEqV8IqcfPxAC7CRx5ax18ua4Z8hb8tM5zKmugG6HZ79bYysLpuKv6cSVD0byQ/1S IFTtOZ2XSB5UKG5wvSVuX1BzPIdKOzbWIeIt2mteaoi7puSPPkdvZ14DMn/TKreC/wES NhXaX9HSKpxb9wYZFuaKm9+NZHkQyc5MotMO5cZ9RFZ59Ip66YYd/J81PIcvcjtOJ+XZ tL0EYInWzVQrHuBItIwLoWrlBBn2G/ylx6pCMPugIWrYucGIOHBEGLGtJtVzL/6fG5jt Vxu0QGZcDuqtRYq/xXCKjUjj/uvMC0rDbPYguuP0rrfRfV93UcH/xWRJL8g2kY27W9OI 8aSQ== X-Gm-Message-State: ALoCoQkRHXuVYCvWkAOukFwAPuGF3ssrpDNuQYlxTIBHZ0VpwfhkdQhf2Zuo/wug0vMBmrWUuj3L X-Received: by 10.70.89.237 with SMTP id br13mr62300876pdb.135.1428640809364; Thu, 09 Apr 2015 21:40:09 -0700 (PDT) Received: from lgmac-pgupta.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id fc3sm670523pdb.22.2015.04.09.21.40.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 21:40:08 -0700 (PDT) Sender: Warner Losh Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Thu, 9 Apr 2015 22:40:12 -0600 Message-Id: <95515F28-A077-4245-90CC-85235C58CAC5@bsdimp.com> References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@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, 10 Apr 2015 04:40:15 -0000 --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2015, at 8:40 PM, Mark Millard wrote: >=20 > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. It should be "-Wl,-m -Wl,elf32ppc_fbsd=E2=80=9D since that=E2=80=99s the = same, isn=E2=80=99t it? That=E2=80=99s what it will do. And that=E2=80=99s= correct. Warner > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Apr-9, at 06:56 PM, Mark Millard = wrote: >=20 > =46rom share/mk/bsd.README : >=20 > LDFLAGS Additional loader flags. Passed to the loader via CC, > since that's used to link programs as well, so loader > specific flags need to be prefixed with -Wl, to work. >=20 > But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/ofw/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/uboot/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/powerpc/Makefile.inc >=20 > In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >=20 >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>=20 >> *** [boot1.elf] Error code 1 >>=20 >> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >> 1 error >=20 > I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that >=20 > -Wl,-m,elf32pcc_fbsd >=20 > is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. >=20 >=20 >=20 > i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >=20 >> LD_FLAGS+=3D -m elf_i386_fbsd >> /usr/src/sys/boot/i386/Makefile.inc >=20 >=20 >=20 > (This note is shorter in part because figured out more context than I = had last time.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVJ1QsAAoJEGwc0Sh9sBEA6LIQAI4XnfOpjioNjyTeAmxllbtu Qfpe2O7n61lD/HzmC7CRQKoHsJyMfjfbBFVV312lOh3tL0cL6arsMyv7WSFQsCFE 7ZXKhjmRAAe/qtviHawg8nIl8N5vu1So56k+zRcJYHlb3x/5iKkAaqwvp85lt0+r Sg2IuQ5rxsTKV3NPR5M0FKrPVklak9s9MMpglell0ZmoU2AysGNiCvFV8lrK8w1p 2lKYdnCmiHhFCRp8Jd8pENQiBv5fKTLykj+z0lKgr6nJbt8qm+QiP6K4ogGv68kj OURz6bcNvRt597UCuUrH9AQ/gbX0zwAM0AjvMPlZnBNMVZDSKIGsnFjw4BUn04pq AcZwTKxCqvJn+pdkvH9rDefx+/RyLzpb68FZoIxZPU87CDilpCno8ALqf+ZnsRQM xXrqDqeqY6n5g7EUhavAfxK7UL/+rAwxxLuVgemdhYptRS/3moUhLfZzWLgqqk5V Yfr9I+6LkDLPtABNgnBppp73B8CUh5feYMbaUi6XmsAlRdvUpp622IWvI1mRAHOS DXjINS68cmwnTajC2fmoCH4L8kyEw3RmXTMfKIs/XkxDKtfYN6z5Vo394dN8EZUU 2NumwO4bis4x8FKUZisSdWuyvZfoboY66C4Uc7swLk6P56wpeluuhaSjuVJaLB/T 0F17NG2b0c4kvQrAr4Z3 =hqHK -----END PGP SIGNATURE----- --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C-- From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 15:44:15 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 E11C0590 for ; Fri, 10 Apr 2015 15:44:15 +0000 (UTC) Received: from perdizione.investici.org (perdizione.investici.org [IPv6:2001:41d0:2:33d0::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6617ABC for ; Fri, 10 Apr 2015 15:44:15 +0000 (UTC) Received: from [94.23.50.208] (perdizione [94.23.50.208]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 80D3F120936 for ; Fri, 10 Apr 2015 15:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1428680652; bh=CMT1zygFsvLSNi8GJ8hX1EGkQoYRTOhVj+6Z49m6I6U=; h=Date:From:To:Subject; b=u7ynHnHoJZHAs+wA9eZS/Zw9/j3ttZdeZarcvLbQ5NIep+T3hqBCCdQt6TStwP6Yq wGDvyDc1aMXrh7HJ5u5Q0oJiLHOG5X6zLRWepEYgYvo8HogbGl4mV+yVXEJb3rRmV2 BezvNvR80QOffO9XTTjBnMK6FgmpKfv+a3UoUdto= Message-ID: <5527EFCB.1000503@paranoici.org> Date: Fri, 10 Apr 2015 17:44:11 +0200 From: aggaz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: FreeBSD on eMac G4 1.25 GHz Content-Type: text/plain; charset=iso-8859-15 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: Fri, 10 Apr 2015 15:44:16 -0000 Dear people of the FreeBSD-PPC world, in the last few days I played with FreeBSD 10.1 RELEASE PPC and an eMac G4 1.25 GHz (PPC). I was able to install the base system without problems (and I add kudos to you because other *BSD were almost impossible to play with (yes, it's my fist tyme with *BSD)). Only problem (at first) was a SegFault while compiling Xorg (the problem was actually Mesa related), but a very friendly user of the #freebsd-xorg IRC channel on EFNet (called dumbbell) solved the issue. He told me to add these lines to /usr/ports/graphics/dri/Makefile just before the line saying ". if (${OSVERSION} >= 901500 && ${OSVERSION} < 1000000)": USE_GCC= yes USE_BINUTILS= yes LDFLAGS+= -B${LOCALBASE}/bin Thanks to him I compiled xorg-minimal. However, I was not allowed to use xf86-video-ati because it says that the port is not PPC compatible, I installed xf86-video-ati-ums instead (as suggested by another helpful user, called Avengence). Given that I was not able to compile any browser, I gave up, and switched back to Debian. I am sad, I liked the idea to start using FreeBSD, but I understand, nobody cares about PPC anymore, even Debian Jessie is too much buggy. I just wanted to tell you that it could be useful to modify the file above to help other users. Best regards Francesco P.S: I am not subscribed to the mailing list, if someone will reply, i would appreciate to be inserted in the "cc". From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 15:52:37 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 35A757F7 for ; Fri, 10 Apr 2015 15:52:37 +0000 (UTC) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 E55E5C38 for ; Fri, 10 Apr 2015 15:52:36 +0000 (UTC) Received: by qku63 with SMTP id 63so34943648qku.3 for ; Fri, 10 Apr 2015 08:52:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i1+M+5sRrBcym5RImuaSfJd/6TgYqN6SUa0IWOR1GUY=; b=gk1G4PcNDKCKvIBNVB5FZv0fSrR/wmhEESNy1cy3psJO7YzYD3dUnwfdAgqpkQuJLI 7G+N+6m0aZ7IyUe3VsBhBShFYvuXtMl9XJYrfubR9sNzM0mrnM5y5+ftOAzx0CWL3C25 gZnU9EWhidwdUBkL6Yhho/aBt5nuvlKGbDVFiOE+vY2oO6xvMms5XJAzi4hzrQTf8tXf Gzkb9SSKQevWvMciG9IQsAm5HhnQCn393Ak44404RstmhfP25CZ8tVAela15SklaNE3e fLcJQ0K8gE1MCx1QCKPB+NZvhD7/t5dfdICcPbuiYsTucLo+BygRs3M1v3kQMy2UPPNF stSQ== X-Gm-Message-State: ALoCoQkw8PqOFPpPJTS1jllPrT4k1RK1idgsrUEdV97GGVRTWSCgl63nvWsrnvFS8jrTbnlwcdPw X-Received: by 10.229.66.198 with SMTP id o6mr2609684qci.31.1428681150466; Fri, 10 Apr 2015 08:52:30 -0700 (PDT) Received: from [10.21.96.160] (static-74-110-169-50.rcmdva.fios.verizon.net. [74.110.169.50]) by mx.google.com with ESMTPSA id 34sm1880842qky.7.2015.04.10.08.52.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 08:52:30 -0700 (PDT) Message-ID: <5527F1BD.9010409@teamblackfox.com> Date: Fri, 10 Apr 2015 11:52:29 -0400 From: Black Fox User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: aggaz Subject: Re: FreeBSD on eMac G4 1.25 GHz References: <5527EFCB.1000503@paranoici.org> In-Reply-To: <5527EFCB.1000503@paranoici.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@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: Fri, 10 Apr 2015 15:52:37 -0000 Hello Francesco, We appreciate the information. Indeed, FreeBSD POWER/PowerPC is hit and miss with a lot of stuff. If you're looking for a neat OS to run on the eMac, you can try MorphOS. Its commercial, and not UNIX-like, but its actively developed for 32-bit PowerPC systems. Best, Black Fox On 4/10/2015 11:44 AM, aggaz wrote: > Dear people of the FreeBSD-PPC world, > > in the last few days I played with FreeBSD 10.1 RELEASE PPC and an eMac > G4 1.25 GHz (PPC). > > I was able to install the base system without problems (and I add kudos > to you because other *BSD were almost impossible to play with (yes, it's > my fist tyme with *BSD)). Only problem (at first) was a SegFault while > compiling Xorg (the problem was actually Mesa related), but a very > friendly user of the #freebsd-xorg IRC channel on EFNet (called > dumbbell) solved the issue. He told me to add these lines to > /usr/ports/graphics/dri/Makefile just before the line saying ". if > (${OSVERSION} >= 901500 && ${OSVERSION} < 1000000)": > > USE_GCC= yes > USE_BINUTILS= yes > LDFLAGS+= -B${LOCALBASE}/bin > > > Thanks to him I compiled xorg-minimal. > > However, I was not allowed to use xf86-video-ati because it says that > the port is not PPC compatible, I installed xf86-video-ati-ums instead > (as suggested by another helpful user, called Avengence). > > Given that I was not able to compile any browser, I gave up, and > switched back to Debian. I am sad, I liked the idea to start using > FreeBSD, but I understand, nobody cares about PPC anymore, even Debian > Jessie is too much buggy. > > I just wanted to tell you that it could be useful to modify the file > above to help other users. > > Best regards > Francesco > > P.S: I am not subscribed to the mailing list, if someone will reply, i > would appreciate to be inserted in the "cc". > _______________________________________________ > 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 Fri Apr 10 16:20:43 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 D87CD336 for ; Fri, 10 Apr 2015 16:20:43 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 5AD29FA6 for ; Fri, 10 Apr 2015 16:20:43 +0000 (UTC) Received: by lbbqq2 with SMTP id qq2so17370015lbb.3 for ; Fri, 10 Apr 2015 09:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=reub6n5L714fpAlEfPLPIQkrMBkqZ42vyQfifo/cGic=; b=qJiNE9PIWgvS4Kg8UZXq/2Ac3MyCRXiHW8KSFQFknGPwMUBk9b/MxusAYbqPilcWW1 ukWFD7Yx9l1K/LoZj08E6pGDlksLMUSOuJRD4yuNe3asnMHyCUys1Q2zX/TU6QJfzZb2 4EMaF/wNoVxuPi4HF9EmH5qItTcse1UbzkHGjG0rVr20+4ERj5+OF5c2ddTkpzjVUzsa U5XTUMzC6+mHFXZ4MfEUPVNcHWtzpyZ/ULPLIBMZFSdbfzWicraRBsOjsEuFXpxS8E/h 71qgH6PE98leuaKG6bQlIjjnIYDq4j/ir+oChSt/VwQgMKmc1AomqX9doK2QxzW2r1fh 89Zg== MIME-Version: 1.0 X-Received: by 10.152.197.34 with SMTP id ir2mr2141937lac.36.1428682841247; Fri, 10 Apr 2015 09:20:41 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.130.5 with HTTP; Fri, 10 Apr 2015 09:20:41 -0700 (PDT) In-Reply-To: <5527EFCB.1000503@paranoici.org> References: <5527EFCB.1000503@paranoici.org> Date: Fri, 10 Apr 2015 09:20:41 -0700 X-Google-Sender-Auth: 6lazo_X8jSbvaxiibwbLOI5BKGo Message-ID: Subject: Re: FreeBSD on eMac G4 1.25 GHz From: Justin Hibbits To: aggaz Content-Type: text/plain; charset=UTF-8 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, 10 Apr 2015 16:20:44 -0000 Could you give more details on the browser? I last built Firefox 35.0, which I'm running on a G5 (powerpc64), but I have had some problems building firefox off and on, for both 32-bit and 64-bit. If you are running into a reproducible problem, please file a PR at https://bugs.freebsd.org/bugzilla/ and someone may take a look at it (most of the ports guys don't seem to have access to a powerpc machine, so rely on others to reproduce problems on this hardware, and propose patches). I can personally say that at least firefox 34.0.5 builds fine for powerpc (32-bit). I haven't built anything more recent than that yet, I haven't updated my 32-bit ports in what looks like 3 months. 32-bit firefox usually builds more reliably than 64-bit for me, too. The most recent Midori fails to build for me because it depends on webkit which has been updated to something unbuildable on powerpc. - Justin On Fri, Apr 10, 2015 at 8:44 AM, aggaz wrote: > Dear people of the FreeBSD-PPC world, > > in the last few days I played with FreeBSD 10.1 RELEASE PPC and an eMac > G4 1.25 GHz (PPC). > > I was able to install the base system without problems (and I add kudos > to you because other *BSD were almost impossible to play with (yes, it's > my fist tyme with *BSD)). Only problem (at first) was a SegFault while > compiling Xorg (the problem was actually Mesa related), but a very > friendly user of the #freebsd-xorg IRC channel on EFNet (called > dumbbell) solved the issue. He told me to add these lines to > /usr/ports/graphics/dri/Makefile just before the line saying ". if > (${OSVERSION} >= 901500 && ${OSVERSION} < 1000000)": > > USE_GCC= yes > USE_BINUTILS= yes > LDFLAGS+= -B${LOCALBASE}/bin > > > Thanks to him I compiled xorg-minimal. > > However, I was not allowed to use xf86-video-ati because it says that > the port is not PPC compatible, I installed xf86-video-ati-ums instead > (as suggested by another helpful user, called Avengence). > > Given that I was not able to compile any browser, I gave up, and > switched back to Debian. I am sad, I liked the idea to start using > FreeBSD, but I understand, nobody cares about PPC anymore, even Debian > Jessie is too much buggy. > > I just wanted to tell you that it could be useful to modify the file > above to help other users. > > Best regards > Francesco > > P.S: I am not subscribed to the mailing list, if someone will reply, i > would appreciate to be inserted in the "cc". > _______________________________________________ > 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 Fri Apr 10 18:19:24 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 43138C1D for ; Fri, 10 Apr 2015 18:19:24 +0000 (UTC) Received: from perdizione.investici.org (perdizione.investici.org [IPv6:2001:41d0:2:33d0::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D091FF08 for ; Fri, 10 Apr 2015 18:19:23 +0000 (UTC) Received: from [94.23.50.208] (perdizione [94.23.50.208]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 950E8121B36; Fri, 10 Apr 2015 18:19:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1428689960; bh=t40gsRZ+3GT5gWP7RFTvBRsCfaI4Gi4WAOfnono/j6M=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=g37eE/kCxPpcuHHiGI5FXVCJ9Zsanz8in0mzeHKm9Dqyj8KhHegSTepoCB8Zhn7YA 6Uvu6HmLRhJ1MEFjWcVQsDX7zIOirKHp5HUsmpGSV06TevKDbbjEb9aYWSSe5zEMmZ M1LhiQkOC4kA7u/kQwaTQE+OUEq0bA3UdP7VibSE= Message-ID: <55281427.8090202@paranoici.org> Date: Fri, 10 Apr 2015 20:19:19 +0200 From: aggaz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Justin Hibbits Subject: Re: FreeBSD on eMac G4 1.25 GHz References: <5527EFCB.1000503@paranoici.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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, 10 Apr 2015 18:19:24 -0000 Dear Justin, I alredy deleted my FreeBSD installation and I can not be very specific. However I remember problems with midori, surf, vimb, and firefox. The cause of the errors were a mixture of compilation problems related to webkit, gtk2 and gtk3. Best Francesco Il 10/04/2015 18:20, Justin Hibbits ha scritto: > Could you give more details on the browser? I last built Firefox > 35.0, which I'm running on a G5 (powerpc64), but I have had some > problems building firefox off and on, for both 32-bit and 64-bit. If > you are running into a reproducible problem, please file a PR at > https://bugs.freebsd.org/bugzilla/ and someone may take a look at it > (most of the ports guys don't seem to have access to a powerpc > machine, so rely on others to reproduce problems on this hardware, and > propose patches). > > I can personally say that at least firefox 34.0.5 builds fine for > powerpc (32-bit). I haven't built anything more recent than that yet, > I haven't updated my 32-bit ports in what looks like 3 months. 32-bit > firefox usually builds more reliably than 64-bit for me, too. The > most recent Midori fails to build for me because it depends on webkit > which has been updated to something unbuildable on powerpc. > > - Justin > > On Fri, Apr 10, 2015 at 8:44 AM, aggaz wrote: >> Dear people of the FreeBSD-PPC world, >> >> in the last few days I played with FreeBSD 10.1 RELEASE PPC and an eMac >> G4 1.25 GHz (PPC). >> >> I was able to install the base system without problems (and I add kudos >> to you because other *BSD were almost impossible to play with (yes, it's >> my fist tyme with *BSD)). Only problem (at first) was a SegFault while >> compiling Xorg (the problem was actually Mesa related), but a very >> friendly user of the #freebsd-xorg IRC channel on EFNet (called >> dumbbell) solved the issue. He told me to add these lines to >> /usr/ports/graphics/dri/Makefile just before the line saying ". if >> (${OSVERSION} >= 901500 && ${OSVERSION} < 1000000)": >> >> USE_GCC= yes >> USE_BINUTILS= yes >> LDFLAGS+= -B${LOCALBASE}/bin >> >> >> Thanks to him I compiled xorg-minimal. >> >> However, I was not allowed to use xf86-video-ati because it says that >> the port is not PPC compatible, I installed xf86-video-ati-ums instead >> (as suggested by another helpful user, called Avengence). >> >> Given that I was not able to compile any browser, I gave up, and >> switched back to Debian. I am sad, I liked the idea to start using >> FreeBSD, but I understand, nobody cares about PPC anymore, even Debian >> Jessie is too much buggy. >> >> I just wanted to tell you that it could be useful to modify the file >> above to help other users. >> >> Best regards >> Francesco >> >> P.S: I am not subscribed to the mailing list, if someone will reply, i >> would appreciate to be inserted in the "cc". >> _______________________________________________ >> 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 Fri Apr 10 21:18: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 06670174 for ; Fri, 10 Apr 2015 21:18:19 +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 B2A8C8B2 for ; Fri, 10 Apr 2015 21:18:18 +0000 (UTC) Received: (qmail 1830 invoked from network); 10 Apr 2015 21:18:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 21:18:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 17:18:11 -0400 (EDT) Received: (qmail 11968 invoked from network); 10 Apr 2015 21:18:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 21:18:10 -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 D5E781C43AF; Fri, 10 Apr 2015 14:18:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: FYI: Some problems with powerpc (non-64) 11.0-CURRENT -r280867: sendmail stack corruption; PRNG not seeded From: Mark Millard In-Reply-To: <3C815370-6DAF-42C7-9CC5-2334F07C9E60@dsl-only.net> Date: Fri, 10 Apr 2015 14:18:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85C392FA-7B2F-4924-9FF3-FBFF9FDCA614@dsl-only.net> References: <3C815370-6DAF-42C7-9CC5-2334F07C9E60@dsl-only.net> To: Nathan Whitehorn , Justin Hibbits X-Mailer: Apple Mail (2.2098) 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, 10 Apr 2015 21:18:19 -0000 Updating to -r281236 with Justin Hibbits=E2=80=99 -r281243 applied (3 = *setjmp.S files updated) fixed both of the following powerpc (non-64) = 11.0-CURRENT problems that I=E2=80=99d FYI'd earlier: A) /usr/libexec/sendmail/sendmail crashing B) "PRNG is not seeded=E2=80=9D status for sshd. Side note: 11.0-CURRENT=E2=80=99s modern powerpc (non-64) is still limited to = (PowerMac) G4=E2=80=99s for my context. The iMac G3 and the PowerMac G5 = boot behaviors are essentially unchanged. ( = https://lists.freebsd.org/pipermail/freebsd-ppc/2015-March/007563.html ) =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference... On 2015-Apr-6, at 06:39 AM, Mark Millard wrote: In my exploring of FreeBSD 11.0-CURRENT on PowerMac's I've noted before = that modern vintages of the powerpc (non-64) do not boot the G5's or the = iMac 3 that I have access to but do boot the G4s that historically = worked. But I've noticed a couple of things that are note working right for the = G4's. I do not know what to attribute them to, unfortunately. Still for = (A) below I've got the evidence about where the segmentation fault is = happening in sendmail. I report on -r280867 specifically just because I've used it a lot more = than somewhat older variants that I'd built before. I doubt that the = issues are unique to -r280867. A) /usr/libexec/sendmail/sendmail is leaving .core files in /var/crash/ = periodically. (Details later below.) B) The attempt to start sshd before login reports that "PRNG is not = seeded". (Details later below.) Basic context: > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG3C0 11.0-CURRENT FreeBSD 11.0-CURRENT #8 r280867M: Mon = Apr 6 02:12:28 PDT 2015 = root@FBSDG5S1:/usr/obj/powerpc.powerpc/usr/srcC/sys/GENERICvtsc-NODEBUG = powerpc powerpc 1100067 1100067 (A few files have to have more recent versions in order to build what is = generally -r280867.) This is a gcc 4.2.1 based build. A) /usr/libexec/sendmail/sendmail is leaving .core files in /var/crash/ = periodically (segmentation fault). (I only have the automatic/default sendmail activity: I never turned it = off but do not use it on the PowerMac's.) As I understand the following: It gets the segmentation fault from r29=3D0= during the code sequence for checking the stack (so the bl to = __stack_chk_fail@plt is not reached). > # gdb /usr/libexec/sendmail/sendmail /var/crash/sendmail.728.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and = you are > welcome to change it and/or distribute copies of it under certain = conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for = details. > This GDB was configured as "powerpc-marcel-freebsd"... > Core was generated by `sendmail'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libutil.so.9...Reading symbols from = /usr/lib/debug//lib/libutil.so.9.debug...done. > done. > Loaded symbols for /lib/libutil.so.9 > Reading symbols from /usr/lib/libwrap.so.6...Reading symbols from = /usr/lib/debug//usr/lib/libwrap.so.6.debug...done. > done. > Loaded symbols for /usr/lib/libwrap.so.6 > Reading symbols from /usr/lib/libssl.so.7...Reading symbols from = /usr/lib/debug//usr/lib/libssl.so.7.debug...done. > done. > Loaded symbols for /usr/lib/libssl.so.7 > Reading symbols from /lib/libcrypto.so.7...Reading symbols from = /usr/lib/debug//lib/libcrypto.so.7.debug...done. > done. > Loaded symbols for /lib/libcrypto.so.7 > Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. > done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. > done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > done. > Loaded symbols for /libexec/ld-elf.so.1 > (gdb) bt > #0 0x4191cac0 in hosts_ctl (daemon=3D, = name=3D, addr=3D, user=3D) > at /usr/srcC/lib/libwrap/../../contrib/tcp_wrappers/hosts_ctl.c:38 > #1 0x4191cabc in hosts_ctl (daemon=3D, = name=3D, addr=3D, user=3D) > at /usr/srcC/lib/libwrap/../../contrib/tcp_wrappers/hosts_ctl.c:32 > #2 0x018322f8 in main (argc=3D6, argv=3D0x6f776e00, envp=3D) at = /usr/srcC/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:2649 > #3 0x01804a24 in _start () > #4 0x418c0fa0 in .text () at = /usr/srcC/libexec/rtld-elf/powerpc/rtld_start.S:112 > (gdb) x/64i 0x4191ca40 > 0x4191ca40 : lwz r0,0(r3) > 0x4191ca44 : mr r3,r29 > 0x4191ca48 : rlwinm r0,r0,2,0,29 > 0x4191ca4c : lwzx r4,r25,r0 > 0x4191ca50 : bl 0x41931890 > 0x4191ca54 : b 0x4191ca10 > 0x4191ca58 : stwu r1,-864(r1) > 0x4191ca5c : mflr r0 > 0x4191ca60 : bl 0x41931594 <.got+548> > 0x4191ca64 : mr r9,r5 > 0x4191ca68 : stw r30,856(r1) > 0x4191ca6c : mflr r30 > 0x4191ca70 : stw r6,8(r1) > 0x4191ca74 : mr r7,r4 > 0x4191ca78 : stw r29,852(r1) > 0x4191ca7c : mr r5,r3 > 0x4191ca80 : stw r0,868(r1) > 0x4191ca84 : li r4,2 > 0x4191ca88 : lwz r29,-36(r30) > 0x4191ca8c : li r6,4 > 0x4191ca90 : li r8,5 > 0x4191ca94 : li r10,3 > 0x4191ca98 : lwz r0,0(r29) > 0x4191ca9c : stw r0,844(r1) > 0x4191caa0 : li r0,0 > 0x4191caa4 : addi r3,r1,16 > 0x4191caa8 : stw r0,12(r1) > 0x4191caac : crclr 4*cr1+eq > 0x4191cab0 : bl 0x41931870 > 0x4191cab4 : crclr 4*cr1+eq > 0x4191cab8 : bl 0x419317b0 > 0x4191cabc : lwz r0,844(r1) > 0x4191cac0 : lwz r9,0(r29) > 0x4191cac4 : xor. r0,r0,r9 > 0x4191cac8 : li r9,0 > 0x4191cacc : bne- 0x4191cae8 > 0x4191cad0 : lwz r0,868(r1) > 0x4191cad4 : lwz r29,852(r1) > 0x4191cad8 : lwz r30,856(r1) > 0x4191cadc : mtlr r0 > 0x4191cae0 : addi r1,r1,864 > 0x4191cae4 : blr > 0x4191cae8 : bl 0x41931810 = <__stack_chk_fail@plt> > 0x4191caec : stwu r1,-896(r1) > 0x4191caf0 : mflr r0 > 0x4191caf4 : bl 0x41931594 <.got+548> > 0x4191caf8 : li r9,128 > 0x4191cafc : stw r30,888(r1) > 0x4191cb00 : mflr r30 > 0x4191cb04 : stw r0,900(r1) > 0x4191cb08 : addi r4,r1,712 > 0x4191cb0c : stw r25,868(r1) > 0x4191cb10 : addi r5,r1,20 > 0x4191cb14 : stw r27,876(r1) > 0x4191cb18 : lwz r25,-36(r30) > 0x4191cb1c : lwz r27,0(r3) > 0x4191cb20 : stw r28,880(r1) > 0x4191cb24 : lwz r0,0(r25) > 0x4191cb28 : stw r0,844(r1) > 0x4191cb2c : li r0,0 > 0x4191cb30 : mr r28,r3 > 0x4191cb34 : stw r23,860(r1) > (gdb) info registers > r0 0xb3a7e38 188382776 > r1 0xffffbb40 -17600 > r2 0x418e4708 1099843336 > r3 0x1 1 > r4 0x41932264 1100161636 > r5 0x0 0 > r6 0x1 1 > r7 0x61 97 > r8 0x0 0 > r9 0x418e4708 1099843336 > r10 0xffffbb20 -17632 > r11 0x4191ed60 1100082528 > r12 0x44000048 1140850760 > r13 0x0 0 > r14 0x6 6 > r15 0x0 0 > r16 0x0 0 > r17 0x1 1 > r18 0x0 0 > r19 0x0 0 > r20 0x18c703c 25980988 > r21 0xffffffff -1 > r22 0x18f2984 26159492 > r23 0x0 0 > r24 0x0 0 > r25 0x1 1 > r26 0x1896608 25781768 > r27 0x0 0 > r28 0x0 0 > r29 0x0 0 > r30 0x41931598 1100158360 > r31 0x0 0 > pc 0x4191cac0 1100073664 > ps 0x0 0 > cr 0x44000048 1140850760 > lr 0x4191cabc 1100073660 > ctr 0x41bd1ad0 1102912208 > xer 0x20000000 536870912 > fpscr 0x0 0 > vscr 0x0 0 > vrsave 0x0 0 My powerpc64 -r280867 build does not have this problem. (But it is a = powerpc64-xtoolchain-gcc based build. I should probably also build and = keep a normal gcc 4.2.1 one at some point.) I listed the above issue first because I had far more detailed/specific = evidence than the below. B) The attempt to start sshd before login reports: > Performing sanity check on sshd configuration. > PRNG is not seeded > /etc/rc: WARNING: failed precmd routine for sshd A "sshd -T" or other such command also reports "PRNG is not seeded". Looking at sysctl output... > kern.random.harvest.mask_symbolic: = UMA_ALLOC,SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CAC= HED > kern.random.harvest.mask_bin: 1111111111 > kern.random.harvest.mask: 1023 > kern.random.yarrow.slowoverthresh: 2 > kern.random.yarrow.slowthresh: 128 > kern.random.yarrow.fastthresh: 96 > kern.random.yarrow.bins: 10 > kern.random.yarrow.gengateinterval: 10 > kern.random.live_entropy_sources:=20 > kern.random.active_adaptor: yarrow > kern.random.adaptors: yarrow(90),dummy(1) does not seem odd to me for 11.0-CURRENT or in comparison to my = powerpc64 build's output. As for what all is non-default for my configuration files (not much)... My use of networking is minimal and the configuration changes for that = are limited to rc.conf: > # more /etc/rc.conf > hostname=3D"FBSDG5C0" > ifconfig_bge0=3D"DHCP" > ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" > ifconfig_gem0=3D"DHCP" > ifconfig_gem0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > #ntpd_enable=3D"YES" > #ntpd_sync_on_start=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > hald_enable=3D"YES" > dbus_enable=3D"YES" I also fiddle with /boot/loader.conf, /etc/fstab, /etc/make.conf, and = /etc/src.conf primarily. /etc/sysctl.conf for dump issues. = /usr/local/etc/sudoers . The rest of the configuration files are at the default/installation = status. My powerpc64 -r280867 build does not have this issue. (But it is a = powerpc64-xtoolchain-gcc based build.) Context details: # svnlite st /usr/srcC/ --no-ignore ? /usr/srcC/.snap ? /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 These are long standing changes associated with my finding a way for = PowerMac G5's to boot reliably (ofw_machdep.c) and getting some evidence = from early boot crashes in case they happen. Also the GENERIC*'s disable = ps3 in order to enable both vt and sc. They do include the standard = GENERIC*'s. Used for building the plain powerpc 11.0-CURRENT -r280867 variant that = produced the backtrace above: # more /etc/src.conf=20 #CFLAGS+=3D-DELF_VERBOSE WITH_DEBUG=3D WITH_DEBUG_FILES=3D # more /etc/make.conf=20 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 Apr 10 21:21:20 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 2A2B7317 for ; Fri, 10 Apr 2015 21:21:20 +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 D3D6097E for ; Fri, 10 Apr 2015 21:21:19 +0000 (UTC) Received: (qmail 21348 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 21:21:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 17:21:18 -0400 (EDT) Received: (qmail 1659 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 21:21:18 -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 6F3BDB1E001; Fri, 10 Apr 2015 14:21:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: Date: Fri, 10 Apr 2015 14:21:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@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, 10 Apr 2015 21:21:20 -0000 I had written: > So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now = based on the notation >=20 > -Wl,-m -Wl,elf32ppc_fbsd >=20 > which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. Based on the system/normal gcc 4.2.1 context I=E2=80=99ve successfully = updated/rebuilt/booted: A) powerpc64 10.1-STABLE -r281235 (self updated from my prior snapshot) B) powerpc64 11.0-CURRENT -r281236 C) powerpc 11.0-CURRENT -r281236 (with -r281243 applied to fix register = save/restore) (B) and (C) were built from (A)=E2=80=99s context (using a separate = 11.0-CURRENT svn-based source tree) and DESTDIR used to installkernel = and installworld to other SSD=E2=80=99s that were being updated. The powerpc64-xtoolchain-gcc experimental update on a different PowerMac = G5 G5 did okay as far as it got based on the notation. But it did not = complete. It will be a while before I research the following references = to compiler support routines for restoring various general purpose = registers. > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m > 32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m -Wl,elf32ppc_fbsd -o = boot1.elf boot1.o ashldi3.o syncicache.o=20 got: > boot1.o: In function `__puts': > boot1.c:(.text+0xf4): undefined reference to `_restgpr_28_x' > boot1.o: In function `__printf': > boot1.c:(.text+0x4fc): undefined reference to `_restgpr_24_x' > boot1.o: In function `ofw_getprop': > boot1.c:(.text+0x628): undefined reference to `_restgpr_31_x' > boot1.o: In function `ofw_close': > boot1.c:(.text+0x694): undefined reference to `_restgpr_31_x' > boot1.o: In function `dskread': > boot1.c:(.text+0x79c): undefined reference to `_restgpr_25_x' > boot1.o: In function `fsread': > boot1.c:(.text+0xce4): undefined reference to `_restgpr_14_x' > boot1.o: In function `domount': > boot1.c:(.text+0xdb8): undefined reference to `_restgpr_28_x' > boot1.o: In function `ofw_write.constprop.2': > boot1.c:(.text+0xe40): undefined reference to `_restgpr_30_x' > boot1.o: In function `putchar': > boot1.c:(.text+0xe90): undefined reference to `_restgpr_30_x' > boot1.o: In function `main': > boot1.c:(.text.startup+0x528): undefined reference to `_restgpr_18_x' > collect2: error: ld returned 1 exit status > *** [boot1.elf] Error code 1 Before the -Wl, notation changes I did not get this far so -WL,-m = -Wl,elf32ppc_fbsd did help. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Apr-9, at 08:46 PM, Mark Millard wrote: I had written: > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now based = on the notation -Wl,-m -Wl,elf32ppc_fbsd which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc = and the other is building 10.1-STABLE -r281235 via the system/normal gcc = 4.2.1. As my builds take considerable time if they actually complete, it will = be a while before I can try any other variations, such as trying a gcc = 4.2.1 cross-build for powerpc. Unfortunately for the purpose at hand: I=E2=80=99m not set up to test = any tier 1 FreeBSD environments at this time. So, for example, I can not = report observations for amd64 building elf_i386_fbsd materials. My tests = may be useful but are not sufficient of themselves to justify edits that = anyone worries might damage tier 1 build-ability. The places I found with notation to adjust if in general the updated = notation works are: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc and the tier 1 case using elf_i386_fbsd: > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference=E2=80=A6 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Apr 11 03:17:18 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 DFB24D3C for ; Sat, 11 Apr 2015 03:17:17 +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 85755F89 for ; Sat, 11 Apr 2015 03:17:16 +0000 (UTC) Received: (qmail 9700 invoked from network); 11 Apr 2015 03:17:15 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Apr 2015 03:17:15 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 23:17:15 -0400 (EDT) Received: (qmail 17364 invoked from network); 11 Apr 2015 03:17:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Apr 2015 03:17:15 -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 A9E741C43AF; Fri, 10 Apr 2015 20:17:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerc64-xtoolchain-gcc with -m32 on powerpc64 vs. lib32/libedit and wchar_t use: gcc 4.9.1 forces __WCHAR_TYPE__ (underlying type?) long int Date: Fri, 10 Apr 2015 20:17:13 -0700 Message-Id: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) 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: Sat, 11 Apr 2015 03:17:18 -0000 I got the following when trying WITH_LIB32=3D with = powerpc64-xtoolchain-gcc (on a powerpc64 box, WITHOUT_BOOT=3D ) : > . . . parse.c:181:25: error: array of inappropriate type initialized = from string constant > const Char hex[] =3D STR("0123456789ABCDEF"); > ^ The rest of this note is about what I found when I looked into this. = Read only if you care. File for later if you likely would care later? =20= The libedit/Makefile uses -DWIDECHAR and libedit/chartype.h defines for = that case: > #define Char wchar_t > . . . > #define STR(x) L ## x > #define UC(c) c There were lots of warnings for incompatible pointer types for libedit/. = . . including the following one that was explicit about which type is = involved: > note: expected 'const wchar_t *' but argument is of type 'long int *' > int wcscmp(const wchar_t *, const wchar_t *) __pure; > ^ So how did the long int type end up involved? I expect the following may = contribute. Turns out that long int (and L suffix use in __WCHAR_MAX__) is specific = to 4.9.1 -m32 handling when compared to gcc 4.2.1 . . . > # gcc -dM -E -m32 - < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647L > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ long int > #define __SIZEOF_WCHAR_T__ 4 and compared to -m64 for both 4.2.1 and 4.9.1 . . . > # gcc -dM -E -m64 - < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m64 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ int > #define __SIZEOF_WCHAR_T__ 4 (where I expect that __WCHAR_TYPE__ is the underlying type used for = wchar_t). The following ended up installed for the 4.9.1 compiler . . . > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/include/conf= ig/rs6000/freebsd64.h > #undef WCHAR_TYPE > #define WCHAR_TYPE "long int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/include/conf= ig/rs6000/sysv4.h =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Apr 11 23:59:00 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 33681489 for ; Sat, 11 Apr 2015 23:59:00 +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 DA66B99B for ; Sat, 11 Apr 2015 23:58:59 +0000 (UTC) Received: (qmail 31575 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Apr 2015 23:58:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 11 Apr 2015 19:58:51 -0400 (EDT) Received: (qmail 22263 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Apr 2015 23:58:51 -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 E3A151C43BC; Sat, 11 Apr 2015 16:58:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?) From: Mark Millard In-Reply-To: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> Date: Sat, 11 Apr 2015 16:58:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3734A273-6178-4AF5-B066-DEEB6CFC7F1C@dsl-only.net> References: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> To: freebsd-ports@freebsd.org, Warner Losh , Baptiste Daroussin X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@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: Sat, 11 Apr 2015 23:59:00 -0000 [The following may point to something that should be directed upstream = for gcc 4.9+ (and possibly earlier?) and/or something for the port(s) to = patch.] Short version: Looking at = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-4.9.1/gcc/config= /rs6000/freebsd64.h shows: > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 The above is what controls the type that results for L". . ." notation = no matter what the FreeBSD typedefs for wchar_t trace back to (int for = powerpc and powerpc64). For FreeBSD that long int should also be just int from what I can tell. = Why? . . . For it being long int: when trying WITH_LIB32=3D for buildworld with = powerpc64-xtoolchain-gcc's powerpc64-gcc port (on a powerpc64 box, using = WITHOUT_BOOT=3D ) this leads to the following in libedit: > . . . parse.c:181:25: error: array of inappropriate type initialized = from string constant > const Char hex[] =3D STR("0123456789ABCDEF"); > ^ where STR(". . .") produces L". . ." and Char traces back to wchar_t = (and back to int for the context). I also got lots of warnings about incompatible pointer types when Char = and STR(. . .) were in the mix for libedit. The ones that mention a type = explicitly mention long int *. I have not checked other processor families: I only have access to = PowerMac based FreeBSD's so far. I have not checked other gcc ports: Are gcc ports that are not = explicitly used for system builds supposed to be well behaved for L". . = ." notation vs. the FreeBSD wchar_t definition for C? If yes then they = likely need the same sort of adjustment. Details/evidence below: Ignore the following if the above is enough. The evidence for what was installed for powerpc64-gcc (on the powerpc64 = box) and what it will treat L". . ." as is: > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647L > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ long int > #define __SIZEOF_WCHAR_T__ 4 The above does not match what gcc 4.2.1 uses for __WCHAR_TYPE__ or what = -m64 uses for either gcc version. Those use int, like FreeBSD does. The long int use seems to be from following = gcc-4.9.1/gcc/config/rs6000/sysv4.h=E2=80=99s conventions for powerpc = (non-64) instead of following freebsd-=E2=80=99s wchar_t being int for = both powerpc and powerpc64: > $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | sort | grep _CALL_ > #define _CALL_SYSV 1 > $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m64 - = < /dev/null | sort | grep _CALL_ > #define _CALL_AIX 1 > #define _CALL_AIXDESC 1 > #define _CALL_ELF 1 In other words: gcc 4.9.1=E2=80=99s freebsd64.h incorrectly assumes that = the call standard to follow drives the choice of underlying wchar_t type = for FreeBSD. The libedit/Makefile uses -DWIDECHAR and libedit/chartype.h defines for = that case: > #define Char wchar_t > . . . > #define STR(x) L ## x Note: I had WITHOUT_BOOT=3D for the experimental buildworld. WITH_BOOT=3D = has both some powerpc Makefile.inc problems (needing to use -Wl, = appropriately) and also there seems to be a lack of bindings for various = _restgpr__x compiler support routines so boot1.elf fails to link. So = I skipped that via WITHOUT_BOOT=3D so I could see what WITH_LIB32=3D = would do. =3D=3D=3D Mark Millard markmi at dsl-only.net