On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote: > On 28.11.2016 19:42, Mark Brown wrote: > > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:
> > 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. So that'll be what changed. But really this is a bug in the multiarch support, zconf.h isn't at all architecture specific within the context of Debian (there's a few things that change but they're all related to completely non-Unix OSs). > > 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. OK, so this makes at least that part of things clearer. It's not a result of linking against the DSO but rather a result of not using an embedded copy of the source. > > 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. Well, there's a bunch of questions there - people seem generally negative on x32 and the use cases for multilib with tooling for early boot and so on don't seem to apply in any case. I'd really have expected that it'd just be added as a new architecture at this point. > > 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. No, it's trying to use a multilib zlib as a dependency. That's still really unclear to me here - to repeat my question above why aren't we asking people who want to build non-native D applications to just install the multiarch runtime? The motivation I'm aware of for still having the multilib packages is to allow other multilib packages to be built with them but I'm not seeing any packages written in D (and it'd be pretty surprising TBH given the narrow use case) so I'm not seeing the use case. > 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. No, that's obviously not a good solution as it just ends up duplicating the source.
signature.asc
Description: PGP signature
