Re: Fwd: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

John Baldwin
On 11/19/19 10:34 AM, Mark Millard wrote:

> [A similar question to the below exists for base/gcc . The lang/gcc* are being ELFv2 enabled for powerpc64 by checking the environment for if it is new enough and already is ELFv2 based.]
>
> Begin forwarded message:
>
> From: [hidden email]
> Subject: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
> Date: November 19, 2019 at 09:32:52 PST
> To: [hidden email]
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813
>
> Gerald Pfeifer <[hidden email]> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Summary|Update lang/gcc8 and        |Update lang/gcc9,
>                   |lang/gcc9 to ELFv2 ABI on   |lang/gcc9-devel, lang/gcc8,
>                   |powerpc64                   |and lang/gcc8-devel to
>                   |                            |ELFv2 ABI on powerpc64
>
> --- Comment #38 from Gerald Pfeifer <[hidden email]> ---
> (In reply to Mark Millard from comment #35)
>> I do not know the intent for devel/powerpc64-gcc relative
>> to future ELFv2 ABI use. Does it need anything? (May be
>> it is updating to gcc9 or some such first?)
>
> Updating to GCC 9 would be my recomendation, though I have no
> involvement with that port.
>
> lang/gcc9-devel should be fine now, both wrt. the new ABI as well
> as building with clang.
>
> Next I'll make the remaining equivalent changes to lang/gcc9 and
> lang/gcc8-devel.

I've just committed a new devel/freebsd-gcc6 port (with flavors) to replace
the powerp64-gcc port (and slaves) with an intention of creating a
freebsd-gcc9 port as a followup.  It seems once freebsd-gcc9 exists we can
apply this change to that.

base/gcc will also similarly be adjusted to base/gcc6 and base/gcc9 in the
future.

The reason to keep old versions is that gcc6 is known to work (for some value
of work) for existing releases, so we want to provide different packages for
different major compiler versions to cope with newer OS releases supporting
newer compilers (e.g. we will patch head to work with freebsd-gcc9, but if
we only had a single powerpc64-gcc port we wouldn't be able to provide a
working compiler for stable/11 if we changed powerpc64-gcc to GCC 9).

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

freebsd-ppc mailing list


On 2019-Nov-19, at 20:14, Mark Millard via freebsd-ppc <freebsd-ppc at freebsd.org> wrote:


> On 2019-Nov-19, at 19:58, Mark Linimon <linimon at lonesome.com> wrote:
>
>>> devel/freebsd-gcc6
>>> devel/freebsd-gcc6@aarch64
>>
>> These two ports are exactly equivalent.
>>
>> I did not have enough time before the commit to puzzle out a way to
>> work around that.  I have limited understanding of flavors.
>>
>> The way it *should* work IMHO is for the former to refuse to build
>> with a message like "is a meta port -- nothing to build."  This is
>> used in several other existing masterports.
>>
>
> Ahh. That helps explain the use of "native" in devel/binutils and
> why it is listed first and that there is a matching default, from
> looking . . .
>
> FLAVORS=        native aarch64 aarch64_none_elf amd64 arm_gnueabi arm_none_eabi \
>                avr i386 mingw32 mips mips64 powerpc64 riscv64 s390x sparc64
> FLAVOR?=        native
>
> Looks like that makes testing for the default (or literal native here) testable:
>
> .if ${FLAVOR} != native
>
> So adding an extra flavor as a default could allow for generating an error?
>
> Thanks for the note. It helped me understand what to expect and what to watch
> out for.
>

Hmm. On an aarch64 machine I could not use:

pkg install freebsd-gcc6@aarch64

after my poudriere bulk run. I had to use:

pkg install freebsd-gcc6

So there are places where the two notations are not equivalent,
despite aarch64 being listed first for freebsd-gcc6's FLAVORS.
One has to know what the FLAVORS list starts with in order to
know what to type in some contexts; one can not just always
type in the @flavor notation.

This was for:

# pkg -v
1.12.0

It reported:

# pkg install devel/freebsd-gcc6@aarch64
Updating custom repository catalogue...
custom repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'devel/freebsd-gcc6@aarch64' have been found in the repositories

The file for the poudriere bulk -f listed:

devel/freebsd-gcc6@aarch64

(despite the context being aarch64 in the first place).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"