tech-pkg archive

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

Re: pre-C++11 compilers



On 07/01/17 10:53, Kamil Rytarowski wrote:
On 01.07.2017 16:27, coypu%sdf.org@localhost wrote:
My understanding is the following:

libstdc++ is mostly backwards compatible, but nowhere near forward
compatible. If we ever use more than one libstdc++, we want to use the
newest for all dependencies.

If it's a leaf C++ package, it's easy - just use the newer GCC to build
it too, and by using g++ it will pull in the newer libstdc++ always.
Most packages that needed it were probably like this. Also, leaf
packages being broken is easy to miss.

If it's a C package, it becomes problematic. using a newer GCC isn't
sufficient to guarantee that a newer libstdc++ will be picked, and it
depends on the link order.

Now we have packages like icu and MesaLib requiring it, which have very
many dependencies, so the chance of encountering the broken scenario is
likely.

NetBSD specifically has an extra complication because it major bumped
libstdc++ in base but pkgsrc GCC still creates the old soname.
I think libstdc++.so.7 and libstdc++.so.6 appear as different libraries?
That should probably be fixed.

I should restore the change to make MesaLib not use the dri option for
older compilers, but luckily it is also controllable by options.

I propose to evaluate a different approach to GCC_REQD.

1. Mark packages requiring minimal GCC/Clang version and just set them
as BROKEN in case of insufficient compiler.

No longer bootstrapping a newer GCC for pkgsrc own purposes, with
exception of bootstrapping gcc packages by self when needed.

2. Abandon the current paradigm of automatically bootstrapping newer C
or C++ compiler to build certain packages.

Temporarily no changes in Fortran handling.

3. Set GCC_REQD when set USE_LANGUAGES.

4. Promote/prepare bootstrap kits with newer toolchain for pkgsrc
platforms. This is task for supported platforms maintainers.

In recent years newer GCC/Clang means newer standard of the C++ language
and incompatible C++ runtime library. As of now and we are now heading
for C++17.. and new set of incompatibilities.

I think this approach is already done by the SmartOS team.


I'm doing it right now to dogfood Clang+ccache on NetBSD with GCC in the
base.
PKGSRC_COMPILER=        ccache clang
CCACHE_BASE=            /usr/local
CCACHE_DIR=             /public/ccache_tmp
CCACHE_LOGFILE=         /tmp/ccache.txt
PKG_CC=                 clang
PKG_CXX=                clang++
CLANGBASE=              /usr/local
HAVE_LLVM=              yes

That might work if we have an official "base" compiler for CentOS 6 that's agreed upon and supported by the pkgsrc community at large.

I've bootstrapped pkgsrc with a home brew GCC in the past and ran into too many issues to resolve by myself.

There are a lot of nuances in GCC/clang builds that pkgsrc can be sensitive to.

It turned out to be easier to work with the native Yum compiler and set GCC_REQD as needed.

Cheers,

    JB

--
Earth is a beta site.



Home | Main Index | Thread Index | Old Index