pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

pkgsrc GCC and libgcc_s

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:

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

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/"

# 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

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.



Home | Main Index | Thread Index | Old Index