ping?
On 30.11.2016 15:31, Matthias Klose wrote:
> 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.
>>
>
