On 30.11.2016 13:45, Mark Brown wrote: > 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).
apparently the Z_U4 definition was generalized in 1.2.8: #if !defined(Z_U4) && !defined(Z_SOLO) && defined(STDC) # include <limits.h> # if (UINT_MAX == 0xffffffffUL) # define Z_U4 unsigned # elif (ULONG_MAX == 0xffffffffUL) # define Z_U4 unsigned long # elif (USHRT_MAX == 0xffffffffUL) # define Z_U4 unsigned short # endif #endif so the files don't differ (anymore), and you can install the header in /usr/include again. The configure script still patches in the HAVE_UNISTD_H and HAVE_STDARG_H definitions, but these always have the same outcome in Debian, plus the libz-mingw-w64-dev package agrees with these definitions too. >>> 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. it's available in the GCC packages for a while now. >>> 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. If we remove everything where "people seem generally negative on FOO", we'll end up with a really small distro. We still require the multilibs for 32bit architectures needing to build 64bit kernels, and I'd rather not ask people to work around issues when they can be fixed. >> 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. >
