From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 03:46:52 2015 Return-Path: Delivered-To: freebsd-toolchain@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 38DB6EE3 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 E504BC83 for ; Fri, 10 Apr 2015 03:46:51 +0000 (UTC) Received: (qmail 11016 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-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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