Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Helmut On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > The problem arises in the reverse sense. If a file does not exist in > one, it is searched in the second and erroneously may be found. That may > make tests pass that should not pass and typically causes a link failure > later. But you want /usr/include to be found. Otherwise you would not be able to use most of the libraries for cross compiling. > . While I do not have a concrete example at hand, I have seen this > pattern repeatedly and generally favour moving stuff out of /usr/include > to avoid this kind of confusion that causes difficult to debug problems. > This also motivates #798955 (in addition to the problem with file > conflicts). In this case here, this would just find kernel headers for a different version. Those are essentially a headers only library, nothing is available for linking. And all the headers provided in /usr/include are the same for all architectures. So moving stuff out of /usr/include might be a good idea if the -dev package is itself arch dependent. > The one case I really do remember quite well is sanitizers. These should > not be enabled in the earlier toolchain stages and failing to disable > them tends to cause linker failures. I don't think it matches the > concrete situation exactly though. You also make a good case in your > followup reporting that gcc-13-cross actually builds. Yep. My problem is: I tested stuff, not everything of course, and did not see any breakage. Also I checked the values I know could influence that and they say it is fine. So at some point I have to assume it is not broken, as exhaustive search is simply not possible. The only statement in this bug report is now: it is located in a different location, so it is broken. No single piece of evidence is shown, like broken builds or some other ways to see the brokeness. Regards, Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > Arguably, a cross toolchain build should probably search > > /usr/include/. I went back and forth a bit with Matthias > > about whether we could add this and did not fully understand his > > reasons, but there is one technical reason we want to avoid it for now. > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > and these packages can have differing versions. When that happens and we > > search both /usr//include and /usr/include/, we'd > > mix two glibc versions with usually bad results (been there). > > But this is a search path. If a file exists in one, the second one is > not found. So nothing can happen even from version skew. The problem arises in the reverse sense. If a file does not exist in one, it is searched in the second and erroneously may be found. That may make tests pass that should not pass and typically causes a link failure later. While I do not have a concrete example at hand, I have seen this pattern repeatedly and generally favour moving stuff out of /usr/include to avoid this kind of confusion that causes difficult to debug problems. This also motivates #798955 (in addition to the problem with file conflicts). > > The other aspect here is that it is not sufficient to add > > /usr/include/ to the search path as you also need > > /usr/include to get a complete linux kernel headers experience. We > > definitely do not want to add /usr/include, because that is known to > > misguide configure tests performed for the target architecture. > > We are talking about the toolchain itself. What configure tests could > that be? Or is that premature optimization of the gcc build? The one case I really do remember quite well is sanitizers. These should not be enabled in the earlier toolchain stages and failing to disable them tends to cause linker failures. I don't think it matches the concrete situation exactly though. You also make a good case in your followup reporting that gcc-13-cross actually builds. > You just said that the search path used during the build of the > toolchain and the one for everything else are unrelated. So you are > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > linux. > > The toolchain as installed already finds all headers. So I still don't > see why we need this in the final system. I find this argument fairly convincing and hope Matthias also does. Thank you Helmut
Packaging of pahole
Hi, I'm eventually acknowledging that I'm poorly suited as maintainer of the dwarves package. I don't follow its development and don't use it either. Thomas as well is asking to be removed from the uploaders, pending signed request. [0] Before opening an RFA, is this team interested in taking over the maintenance? I think it's mostly used by the kernel build, I'm not aware of any other users. Regards, Domenico [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065134#15 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Processing of iw_6.7-1_source.changes
iw_6.7-1_source.changes uploaded successfully to localhost along with the files: iw_6.7-1.dsc iw_6.7.orig.tar.xz iw_6.7-1.debian.tar.xz iw_6.7-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
iw_6.7-1_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 05 Mar 2024 00:17:19 +0100 Source: iw Architecture: source Version: 6.7-1 Distribution: unstable Urgency: medium Maintainer: Debian Kernel Team Changed-By: Paride Legovini Changes: iw (6.7-1) unstable; urgency=medium . * New upstream version 6.7 * d/u/signing-key.asc: update signing key * d/control: apply wrap-and-sort -kbast * d/control: replace B-D on obsolete pkg-config with pkgconf Checksums-Sha1: 42b75eb457cd2bac21724b2d0d9503fd13fd3ca6 1575 iw_6.7-1.dsc 663fecbee403237710f8db044fcd34890d479942 158928 iw_6.7.orig.tar.xz 650da11e24a3c6ef0ba6fabf6f051aabb8c07de8 25204 iw_6.7-1.debian.tar.xz 48f526170a7faa2a5f997e543576eea04a6ffd54 5795 iw_6.7-1_amd64.buildinfo Checksums-Sha256: 790f3e8973c3141de1e8f82f72a016648b7559dfe0150a6ee9d5c3c8c9faee85 1575 iw_6.7-1.dsc aacf49c266b29d500d73086798a1c652e760c19126a8599fd811850430789a35 158928 iw_6.7.orig.tar.xz 81bcc08c18cffb32576a57b8846bd85b8af7deeef746184b43e64b04b8e36698 25204 iw_6.7-1.debian.tar.xz ac3ad04b5af33418409bde5a219e2e1398aceafe97efede283b34a6aa4065ed2 5795 iw_6.7-1_amd64.buildinfo Files: 4ebc706f3016782050c7ea34687e5887 1575 net optional iw_6.7-1.dsc a63e81b0dcae9caf9ed3a20f2c445a07 158928 net optional iw_6.7.orig.tar.xz ae743f69cee52c9f87626f62ebb6e317 25204 net optional iw_6.7-1.debian.tar.xz 54b93e7032c249bd8776cd2ec5d959bc 5795 net optional iw_6.7-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEVhrVhe7XZpIbqN2W1lhhiD4BTbkFAmXm+R8SHHBhcmlkZUBk ZWJpYW4ub3JnAAoJENZYYYg+AU25ARcH/3vJINLN0YRoI3YOIcqfhKH9JSQe5Vs7 f7JuzrKXj3udgAIe1M/xffLJqp2T0sus8nrzkyWVGHwSBW0hqhC0Ca8hPjDfLj4E fCy78+ody49zIgyeXmIiSUVeXekhmuErWRI3F1Hb7O9Ku0dot/kKStunn/rqXzvz HsaqZun5o4oHTax6tCA7wzcNbaaeDi3ADXMiRwtO0kaqNu9upA47yhtFX8klVqlt 3PSQcJEE1zHI45RGrUM8jxVnbfFJWxJVR88o6Q8VqwPOvyYiD0gc6TF+dNqwvSXu 9UKgmS0bk/ne72c2SlhWI6CxZT+8WinUha/LFqqiInmfXrlAzkEWJ4Q= =yja0 -END PGP SIGNATURE- pgp87hUnhM4Mr.pgp Description: PGP signature
