sys-libs/binutils-libs provides a reduced set of binutils, that ships just the minimal libraries that might be consumed at runtime from binutils. Please introduce a package, sys-libs/gcc-libs, that provides the same thing for GCC. sys-libs/libstdc++-v3 used to do this for JUST libstdc++, but it's not really updated. The libs that it will need to ship: libgcc_s.so.1 libgomp.so.1 libstdc++.so.6 libgfortran.so.5 (optional) For amd64, this would be 5.5MiB for each 32 & 64bit, 11MiB total, instead of 500MiB-1G in size. The main benefactors of this would be containerized Gentoo, where the environment is not expected to further build anything at all. Infra is interested in this for improving the size of new projects.
It's a good idea to have smaller libraries for gcc runtime, but not very easy to implement today. A few notes first: 1. sys-libs/libstdc++-v3 never provided usable set of usable libstdc++ libraries. It's a binary-only package for libstdc++.so from gcc-3.3 when ABI broke. Note how it's build compiles full gcc and installs only shared libraries. But not headers for example. It makes them usable only for binary packages only. 2. sys-libs/binutils-libs is not a reduced set of libraries. These are normal libraries people can link and build against and rely on a subslot to trigger rebuilds. sys-devel/binutils does not provide a nice way to install a library and headers in a way that triggers rebuilds of users. Or in a way that non-native ABI could build it. We have to set very unusual SONAMEs to avoid accidentally mixing them with libraries that come from sys-devel/binutils. Note specifically: sys-devel/binutils itself does not link against sys-libs/binutils-libs and uses it's own internal libraries. Now for the mechanics: gcc's build system does not allow for easy decoupling of gcc/libstdc++. gcc uses it's own libstdc++ and vice versa libstdc++ relies on gcc's c++ standard it implements. gcc uses internal libraries for linking as well. Runtime story is a bit unusual: we expose latest libraries when multiple gcc versions are installed. It works most of the time. Having separate libraries we would have to maintain the same requirement: separate libraries would have to have latest version and yet not take part in intermediate linking. gcc provides a lot more libraries than just libgcc_s.so.1 libgomp.so.1 libstdc++.so.6 libgfortran.so.5. If we follow the path of sys-libs/binutils-libs we might build full gcc and install only final libraries instead of current symlink handling. We'll need a more detailed plan to keep system running for upgrades of such libraries.
(In reply to Sergei Trofimovich from comment #1) > gcc provides a lot more libraries than just libgcc_s.so.1 libgomp.so.1 > libstdc++.so.6 libgfortran.so.5. Those libraries the only ones that seem to be linked by binaries generated by GCC. All the other libraries are used by GCC itself. Two more that I see as a maybe, but I haven't found something in Gentoo that seems to use them yet: libquadmath libitm
(In reply to Robin Johnson from comment #2) > (In reply to Sergei Trofimovich from comment #1) > > gcc provides a lot more libraries than just libgcc_s.so.1 libgomp.so.1 > > libstdc++.so.6 libgfortran.so.5. > Those libraries the only ones that seem to be linked by binaries generated > by GCC. All the other libraries are used by GCC itself. Good point. > Two more that I see as a maybe, but I haven't found something in Gentoo that > seems to use them yet: > libquadmath > libitm 'gcc -dumpspecs' has a few more examples: vtv asan/ubsan/tsan gomp atomic
I need this too. gcc is a big pkg, too big for embedded/binary only systems and there gcc-libs is a must. On a related note, glibc's locale part should be split to a separate pkg. All those locales take a lot of space and is source code to localedef. A new locale pkg in minimal form should just install the selected locales into locale-archive. Wonder if gconv/iconv could be separate/USE flag too?
(In reply to Joakim Tjernlund from comment #4) > I need this too. gcc is a big pkg, too big for embedded/binary only systems > and there gcc-libs is a must. The current workaround is to copy individual libraries over manually on a target system. > On a related note, glibc's locale part should be split to a separate pkg. > All those locales take a lot of space and is source code to localedef. > > A new locale pkg in minimal form should just install the selected locales > into > locale-archive. > > Wonder if gconv/iconv could be separate/USE flag too? Please file a separate bug report. This bug is about gcc related files.
(In reply to Sergei Trofimovich from comment #5) > (In reply to Joakim Tjernlund from comment #4) > > I need this too. gcc is a big pkg, too big for embedded/binary only systems > > and there gcc-libs is a must. > > The current workaround is to copy individual libraries over manually on a > target system. Yes, but that is very crude and does not handle updates well. It is not easy to know which libs exactly either. > > > On a related note, glibc's locale part should be split to a separate pkg. > > All those locales take a lot of space and is source code to localedef. > > > > A new locale pkg in minimal form should just install the selected locales > > into > > locale-archive. > > > > Wonder if gconv/iconv could be separate/USE flag too? > > Please file a separate bug report. This bug is about gcc related files. https://bugs.gentoo.org/785064
Not really happy with this idea, unless it is supported explicitly by upstream. We already have enough toolchain fun.
