Hello Sylvestre. Packages llvm-toolchain-6.0 and llvm-toolchain-7 in buster show the same behaviour in my building environment than llvm-toolchain-3.8, but before reopening/cloning this bug it may be worth to comment here first.
Back in 2016, you said: > I am building the LLVM toolchain twice a day on 2 architectures > for 8 Debian/Ubuntu releases + maintain Debian packages. I think the > process is reliable enough for Debian. Well, I also do this kind of reasoning when I receive a bug which is so weird which is almost impossible to believe that it could happen. For example, if somebody reports that "ls" segfaults, one would probably think that it's a problem in the user's machine, like filesystem corruption, memory corruption, or something alike, because otherwise a lot of people would notice. However, continuous testing and jenkins only help to discover bugs which happen in a similar environment. So, for example, if you always build llvm in multi-cpu machines and it happens that it does not build ok in single-cpu machines, the fact that you build llvm twice a day on several differentr architectures will not help to discover such kind of bug. And that's precisely my theory here: I believe llvm build has never been tested in a single-CPU system. So: Would be possible for you to try building the package on a single-cpu system at least once? (I can provide a virtual machine for you if setting up such a system is a burden for you). (If my suspicious is true, the subject ("build not reliable") would fit. I would call a build "reliable" when its success or not does not depend on things not in debian/control, i.e. when it builds ok in both slow or fast computers, and regardless of vendor or number of CPU cores. This is what I would expect from an Operating System which prides to call itself Universal, and also this is the spirit of Debian Policy when it says that "it must be possible to build the package when build-essential and build-dependencies are installed". We don't have a control field to require more than one CPU). (Note: If you are wondering why I'm using single-CPU systems for my QA work: They are usually cheaper and more efficient per €. In my experience, multi-cpu is only "better" when you don't have to pay for it). Sorry for the long email. Thanks a lot.