On 28.11.2016 19:42, Mark Brown wrote: > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote: >> On 26.11.2016 20:35, Mark Brown wrote: >>> On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote: >>>> On 26.11.2016 19:42, Mark Brown wrote: >>>>> On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote: > >>>> This exactly is the correct issue, not "some random bug". > >>> I'm afraid I'm still unclear what you are trying to do or why. > >> well, you removed the example from your reply and didn't comment on it. > > That is one of several different things you've been talking about which > seem to be related somehow to at least one underlying goal. I'm still > trying to figure out that underlying goal here to work out what the most > sensible thing to do is. > >> The example fails because the zconf.h header is not found. You can see the >> list >> of the standard include paths when calling gcc with the -v option. > > Which apparently changed at some point in the toolchain, probably quite > some time ago, but fortunately we'd actually managed to remove all the > users before that happened so it didn't affect anyone.
Wrong. Until the zconf.h header was moved from /usr/include to /usr/include/<multiarch> these packages found the *wrong* header in /usr/include, now they don't find anything anymore. > Right now as far as I can tell there's been some change in the GNU D > compiler that's attempting to add usage of the multilib zlib versions > for some reason which is not at all clear to me. You said something > about moving the GDC runtime to a shared library but I'm finding that > confusing as the issue with the header file as should also affect static > usage so it seems like there must be something else in the mix > somewhere. The libphobos configury falls back to the zlib copy shipped within the GCC sources, when the system zlib cannot be used. So sure, dropping the build dependencies on the multilib zlib packages does use the embedded copy, but that's not what you usually want to do. > It seems there's also something going on with x32 but as far as I can > tell that's orthogonal though it does seem to be related to changes in > GDC as well somehow. that's just the third multilib on amd64 and i386. > As things stand it seems like the best thing to do just looking at this > issue by itself is remove the multilib zlib packages since they've been > broken for some time without anyone noticing and we have multiarch so > there shouldn't be any need for new users. However I don't want to just > upload that right now since you're looking to add new users though I'm a > bit confused as to why, it seems like a step backwards. > > Shouldn't people building i386 D programs on amd64 (or other similar > builds that would historically have been done with multilib) just be > using multiarch to install the 32 bit runtime? Please bear in mind > that I'm not at all familiar with D here. there's nothing you need to understand with D, just that it tries to use zlib as a dependency. So removing these packages is fine with me too; in this case, please wait with the removal and I'll prepare a new source package to build these multilib libraries for the stretch release. Matthias
