pkgsrc GCC and libgcc_s

[Jason Bacon <outpaddling%yahoo.com@localhost>]

Note to posterity...

The recent default removal of libgcc_s* from the GCC packages broke my 
system for using a newer GCC as a "base" compiler on Enterprise Linux 
(EL - RHEL, CentOS, SL, ...).

Context for those new to the conversation: RHEL/CentOS systems are 
basically heavily patched snapshots of several-year-old Fedora 
distributions.  The current mainstream RHEL 7 uses GCC 4.8 as its base 
compiler.  Many open source packages require newer GCC versions.  A 
newer GCC can also take better advantage of new CPU features.

My solution is to use a pkgsrc GCC to build everything except GCC itself 
and its dependencies.  The system facilitates the installation of 
bleeding-edge open source packages on EL.  It's a bit complicated to 
explain but is automatically configured by auto-pkgsrc-setup:

    http://netbsd.org/~bacon/

This strategy is likely useful on other platforms with outdated base 
compilers as well.

Another approach it to bootstrap pkgsrc from a home-grown GCC 
installation instead of the native GCC, but that's not very portable or 
reproducible.

The new problem:

The pkgsrc GCC packages were recently modified to remove libgcc_s.* by 
default, to avoid confusion in cases where multiple GCC versions are in 
play (a situation that should be avoided, but nevertheless occurs).

On EL systems, this results in "cannot find -lgcc_s" link errors for 
packages using pkgsrc GCC.

This might be something that could be addressed in the GCC packages, but 
it's messy to separate the numerous Linux distributions and using pkgsrc 
GCC is unnecessary on bleeding-edge systems such as Debian, Ubuntu, ...

Fortunately the gcc maintainers had the foresight to provide an 
"always-libgcc" option to disable the removal of libgcc_s.so.

Below is a simple workaround for mk.conf that uses this option to avoid 
the issue.  It also includes a patch to use pkgsrc binutils, which is 
necessary with newer compilers that might generate machine instructions 
not known to the EL "as" command (especially if using flags like 
-march=native on newer CPUs).

# Keep this in sync with pbulk-setup
.if exists(/etc/redhat-release) && !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

It would be nice instead to make the GCC packages work out-of-the-box on 
EL, but prior conversations about this have revealed how complicated it 
is to achieve.  This is the simplest fix I've discovered so far and 
again, it's done for you by auto-pkgsrc-setup.

Best,

    JB