Toolchains, cross-toolchains, and libstdc++ dependencies
This page covers issues and possible solutions around the subject of libstdc++ being closely coupled to the gcc/g++ sources. This primarily affects cross-compiler builds and the use of alternate compilers such as clang.
1) clang can't install c++ headers without also installing g++, because libstdc++6-4.*-dev depends on g++-4.*. This makes clang effectively depend on g++, which it doesn't need or want.
2) libstdc++6-4.*-dev is not multiarch:same so g++-<triplet> can't install c++ headers for arch <triplet> using multiarch, because they are not co-installable with the native version of libstdc++6-4.*-dev
Packages which build-depend on libstdc++(-dev)
Packages which build-depend on libstdc++
Package: aghermann Package: balder2d Package: golly Package: nsis Package: nxcl Package: pkcs11-dump Package: shotdetect Package: socnetv Package: aghermann Package: balder2d Package: golly Package: nsis Package: nxcl Package: pkcs11-dump Package: shotdetect Package: socnetv
Packages which build-depend on libstdc++-dev:
Package: nxcl Package: pkcs11-dump Package: shotdetect Package: socnetv Package: nxcl Package: pkcs11-dump Package: shotdetect Package: socnetv
DebConf12 BoF minutes
Preventing another copy of the same headers for each architecture for which a cross-compiler is needed.
- - because libstdc++6-4.7-dev-armhf-cross has the exact same contents as libstdc++6-4.7-dev:armhf, so why can't we use the copy that's already in the archive? - does this become more brittle in terms of dependencies? - C++ is being treated specially right now as a front end; Toolchain maintainer (Matthias) intended to merge the libstdc++6-4.7-dev package *into* g++. Going the other way, we should look at all the frontends (objc, fortran)
=> This solution would cause some problems to clang (clang depends on libstdc++6-4.7-dev for the C++ headers). It would help clang to have libstdc++6-4.7-dev without the g++ dependency (idem for objc. See bug #680784) => However, clang needs object files from gcc (crt1.o etc.)
Matthias also wants binaries to be moved to /usr/libexec instead of being in the gcc directory
- /usr/libexec - the search assumes there's libexec vs. lib, and gcc would maybe need patching upstream to look in right places
So Someone needs to do the split and check it works for the native compiler still.
Need libgcc-4.7-dev, libgobjc-4.7-dev and libstdc++6-4.7-dev independently installed from gcc all .a, .h, and .so* files which are currently in gcc, gfortran or gobjc need to move into lib*-$version-dev packages. The gobjective C multilib libraries become pure dependency packages. gobjc++-4.7-multilib
No c++ library should be linked to libc++ (the LLVM C++ implementation) Set /usr/bin/cc & /usr/bin/c++ explicitly and remove assumptions that this is gcc to increase support for clang and gcc-$triplet. Need more exact details of the work to be done - wookey & Thibg. List of files for which packages etc. Probably add another 20-25 binary packages built from gcc source.
proposed gcc packaging changes (cross and native)
- split out a libgcc-4.7-dev package (holding all the .a, .so, .h files found in cpp-4.7/gcc-4.7. This will hold the start files, and the libgcc_s, libgcc, libquadmath, libgomp and libitm development files.
- split out libobjc-4.7-dev and libgfortran-4.7-dev packages
- do the same with Go, Ada, Java
- have corresponding multilib packages (lib64gcc-4.7, etc). This is which currently is in the -multilib. Then make the -multilib packages dependency packages.
- Don't ship any .h, .a, .so files in the cross compiler packages, but lookup the files in the new -dev packages. This may need changes to the driver (gcc), and maybe moving the binaries (cc1, cc1plus, etc) to it's own path, e.g. libexec.
Please avoid adding cross-architecture build dependencies for the native gcc packages. gcc and glibc still should be built using the multilib approach.