Summary: | sys-libs/gcc-libs: new that provides a minimal runtime-only set of libraries | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | gentoo, infra-bugs, joakim.tjernlund, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=812938 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Robin Johnson
2020-02-21 08:05:24 UTC
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. |