Date: Thu, 9 Apr 2015 20:46:48 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) Message-ID: <B6CA80BE-721E-415D-A87A-6AD7ED69235D@dsl-only.net> In-Reply-To: <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <E0A6C671-A4FF-4EE9-B260-1EF615ECA62E@bsdimp.com> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp at bsdimp.com> wrote:
>=20
>> On Apr 9, 2015, at 7:56 PM, Mark Millard <markmi@dsl-only.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6CA80BE-721E-415D-A87A-6AD7ED69235D>