Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
The and headers need their counter parts and from the libc respectively, but libstdc++ wraps these headers. Now and include these headers using $ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null In file included from :1: /usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ compilation terminated. $ What happens here is that g++ includes libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines _GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next . libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h happens to come earlier and is not considered. Unfortunately, the -isystem above inserted glibc's header before the location containing , so the #include_next continues searching and fails to find . Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. #include_next is simply not useful here. The #include_next was originally added via PRs libstdc++/14608 and libstdc++/60401. At that time, the _GLIBCXX_INCLUDE_NEXT_C_HEADERS guard macro was also added. It seems like the #include_next was a meant as an extra safe-guard, but actually breaks a practical use case. For these reasons, I think that using #include_next here is harmful and that replacing it with plain #include solves the problem without introducing regressions. [1] Including but not limited chromium-browser, inkscape, various kde packages, opencv, and vtk. libstdc++-v3/ChangeLog: * include/c_global/cmath: Don't use #include_next. * include/c_global/cstdlib: Likewise. --- libstdc++-v3/include/c_global/cmath | 2 +- libstdc++-v3/include/c_global/cstdlib | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Given the patch's size, I think that the copyright dance is not necessary. The issue affects at least gcc-8 to gcc-10. Please Cc me in replies. Helmut diff --git a/libstdc++-v3/include/c_global/cmath b/libstdc++-v3/include/c_global/cmath index b99aaf8df40..8b2bb7c0785 100644 --- a/libstdc++-v3/include/c_global/cmath +++ b/libstdc++-v3/include/c_global/cmath @@ -42,7 +42,7 @@ #include #include #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS -#include_next +#include #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include diff --git a/libstdc++-v3/include/c_global/cstdlib b/libstdc++-v3/include/c_global/cstdlib index f42db41fc51..80b39f6144f 100644 --- a/libstdc++-v3/include/c_global/cstdlib +++ b/libstdc++-v3/include/c_global/cstdlib @@ -72,7 +72,7 @@ namespace std // Need to ensure this finds the C library's not a libstdc++ // wrapper that might already be installed later in the include search path. #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS -#include_next +#include #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include -- 2.26.0
Bug#910685: glibc: please support DPKG_ROOT
Hi Aurelien, On Tue, Apr 14, 2020 at 05:49:38PM +0200, Helmut Grohne wrote: > Yes, please. Is there anything blocking this? Without support in glibc, > moving forward is a little difficult. Can you include it soonish? I pinged Aurelien on IRC about this. Let me summarize your answer here: * The relevant maintainer scripts are fragile. Experience has shown that every time one touches them they break. They should be well-tested. * Does the patch actually make libc6 work the way it advertises? * What about libc-bin? * Why not move forward with more testing of more packages before applying this patch? Yes, that makes sense. Let me give a partial answer already. I've performed a number of upgrades from unstable to patched libc packages in buildd-like environments now. The coverage is limited. I've set up a little testing lab to build patched versions of base-files, bash, coreutils, debhelper, debianutils, dpkg, glibc, shadow and util-linux. When installing subsets of essential using these patched packages, few packages fail to install. The failures are base-files, base-passwd, bash, dash, debconf, libc-bin, libpam-modules-bin, libpam-modules, libpam0g, login, mawk, sysvinit-utils, and util-linux. The majority of failures is due to missing patches for debconf. libc-bin is notable here as it will need changes to ldconfig to support this use case. However, very few packages depend on libc-bin. Therefore, I think solving libc-bin at a later time is reasonable. Small steps have been made in various packages: https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/4 https://salsa.debian.org/debian/shadow/-/merge_requests/10 https://salsa.debian.org/debian/shadow/-/merge_requests/11 https://salsa.debian.org/debian/debianutils/-/merge_requests/5 Guillem Jover resumed up work on dpkg-maintscript-helper and update-alternatives. In any case, I think that this patch does indeed make the library (not libc-bin) work for DPKG_ROOT and I'd prefer libc-bin to be handled in a separate issue. So yeah, we can move forward without this being merged if we really want. Questioning whether this patch blocks progress was a useful thing to do. There will be more fixes. Helmut
Bug#954230: In a sticky directory root cannot write to files owned by normal users
Sounds like protected_regular from https://www.kernel.org/doc/Documentation/sysctl/fs.txt ttfn/rjk
