On Fri 06 Oct 2023 at 06:22:03 -0700, Jason Bacon wrote:
> We discussed this issue years ago, relating to RHEL6, whose gcc 4.8
> compiler was not up-to-snuff for many packages. I ended up making
> auto-pkgsrc-setup insert the following into mk.conf as a workaround
> (along with GCC_REQD and many exemptions for gcc deps).
>
> https://github.com/outpaddling/auto-admin/blob/master/User-scripts/auto-pkgsrc-setup
>
> .if (exists(/etc/redhat-release) || exists(/etc/amazon)) &&
> !empty(PKGPATH:Mlang/gcc*)
>
> # RHEL systems may have an outdated "as" that cannot translate instructions
> # from current GCC code generators, so force pkgsrc binutils.
> CONFIGURE_ARGS+= --with-gnu-as --with-as=\${PREFIX}/bin/gas
> CONFIGURE_ARGS+= --with-gnu-ld --with-ld=\${PREFIX}/bin/gld
> BUILDLINK_DEPMETHOD.binutils= full
> . include "../../devel/binutils/buildlink3.mk"
>
> # pkgsrc gcc packages don't install libgcc_s on some platforms, to
> # avoid problems when mixing compiler versions. This breaks our use
> # of pkgsrc gcc on EL.
> PKG_DEFAULT_OPTIONS+= always-libgcc
> .endif # RHEL
So then you end up with two versions of libgcc_s? Is the later one
strictly an extension to the earlier version? Maybe the version that
goes with gcc12 should be renamed so that the two versions won't
conflict? (just having different major version numbers leads to some
chaos, as we see with -lstdc++)
I suppose, in the longer term, the new functions in libgcc_s should be
put into the base system version. But that doesn't help for the short
term.
A short term hack could be to overwrite the base system version with
gcc12's version... but that is a terrible hack. And it can only be done
if they are compatible enough.
Would it make sense to make a static library? Or maybe one for gcc12
with only the extra functions in it?
-Olaf.
--
___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work. --I. Rose
Attachment:
signature.asc
Description: PGP signature