Wrong OSABI for GCC from Ports

[Alex Arslan]

I noticed that GCC and its associated libraries, when installed from pkg
on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than
FreeBSD (9), as reported by readelf --file-header. I also observed this
when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I
assumed it was an issue with the cross compilation setup until I realized
that the one from pkg exhibited the same thing. This does not seem to
occur with x86_64, neither from pkg nor cross compiled. Does anyone know
why this would happen and whether it could be addressed with a patch to
GCC? Apologies if this is already known and has been discussed somewhere.

Thanks!


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lorenzo Salvadore]

Post by Alex Arslan
I noticed that GCC and its associated libraries, when installed from pkg
on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than
FreeBSD (9), as reported by readelf --file-header. I also observed this
when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I
assumed it was an issue with the cross compilation setup until I realized
that the one from pkg exhibited the same thing. This does not seem to
occur with x86_64, neither from pkg nor cross compiled. Does anyone know
why this would happen and whether it could be addressed with a patch to
GCC? Apologies if this is already known and has been discussed somewhere.

Hello,

I am the maintainer for the GCC ports, sorry for the late response.
I have created a bug report to track this issue, so we do not forget
about it:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281681

Is the bug only about the value reported by readelf? Or is the compiler
actually broken? If the compiler works, what is the value reported by
readelf for binary compiled by it?

Thanks for your bug report,

Lorenzo Salvadore


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alex Arslan]

Post by Lorenzo Salvadore

Post by Alex Arslan
I noticed that GCC and its associated libraries, when installed from pkg
on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than
FreeBSD (9), as reported by readelf --file-header. I also observed this
when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I
assumed it was an issue with the cross compilation setup until I realized
that the one from pkg exhibited the same thing. This does not seem to
occur with x86_64, neither from pkg nor cross compiled. Does anyone know
why this would happen and whether it could be addressed with a patch to
GCC? Apologies if this is already known and has been discussed somewhere.

Hello,
I am the maintainer for the GCC ports, sorry for the late response.
I have created a bug report to track this issue, so we do not forget
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281681

Thank you! Mikäel Urankar pointed out that what I described sounds similar
to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252490 and I believe
it is actually the exact same phenomenon as what I described.

Post by Lorenzo Salvadore
Is the bug only about the value reported by readelf? Or is the compiler
actually broken? If the compiler works, what is the value reported by
readelf for binary compiled by it?

The compiler itself works just fine, it's only the OS/ABI in the ELF file
header that isn't set to FreeBSD. It does have a FreeBSD branded ELF note
though. Binaries produced by cc set OS/ABI to FreeBSD and include the ELF
note, whereas binaries produced by the GCC port (13.2.0) have OS/ABI set
to NONE but do still include the branded ELF note. The produced binaries
are similarly functional.

Based on the discussion in Mikäel's bug report, it sounds like this
behavior is expected, so I guess there's no bug after all?

Post by Lorenzo Salvadore
Thanks for your bug report,
Lorenzo Salvadore

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de