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:
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
Home |
Main Index |
Thread Index |
Old Index