Re: jessie release goals
On 13/05/13 18:26, Stephen Kitt wrote:
> Yes, but that's not the problem. Take the premise that the target
> directory structure is as described above, so most library
> development packages ship as many headers as possible in
> /usr/include. For now we'll assume all mingw-w64-...-dev headers
> are in /usr/include/...-w64-mingw32; but to use mingw-targeted
> libraries other than mingw-w64-...-dev (libgtk for example), the
> mingw toolchain needs to look in /usr/include as well.
Gtk isn't a great example here; to use Gtk, you have to look in the
directories listed in its pkg-config metadata, none of which are on
the default search path (making Gtk 2 and Gtk 3 co-installable). The
same argument would be valid for, for instance, libgcrypt, though.
> But in a typical work environment, libc6-dev will be installed, and
> because we'll always be cross-compiling on the buildds, packages
> which need to build stuff for the host to run during the build
> (wine-gecko does this) need build-essential too, so libc6-dev
> headers end up in /usr/include and are picked up by the mingw
> toolchain.
You could argue that the bug here is that multiarch glibc development
packages are not sufficiently multiarch: they install headers to
/usr/include that are valid and identical for all *Debian* host
architectures (*-linux-gnu*, *-kfreebsd-gnu and i386-gnu), but are not
valid/identical for, for instance, *-w64-mingw32 or *-solaris. I don't
think they're valid for alternative Linux libcs (klibc, dietlibc etc.)
either, for that matter.
That's partly a property of libc's special status as part of the
definition of the OS ABI; ordinary libraries don't need as much
variation as libc. For instance, libjpeg puts all its headers in
/usr/include, except for /usr/include/TUPLE/jconfig.h.
libdbus and GLib combine "not in the default search path" with the
same setup as libjpeg: libdbus' only architecture-dependent header is
/usr/lib/TUPLE/dbus-1.0/include/dbus/dbus-arch-deps.h (which should
perhaps be somewhere in /usr/include/TUPLE, but this setup is older
than multiarch, and overriding it seems like busy-work).
> As far as I can see there are three solutions to this: * split
> headers completely
or, a slight refinement of that:
* split all headers that would differ on *any* platform, even platforms
not supported by Debian (e.g. those that do not use glibc)
> The aim of all the mingw work as far as Debian is concerned, apart
> from providing a nice mingw build environment, is to provide a
> wine-mono package, which needs a whole bunch of dependencies.
win32-loader is another purpose for mingw stuff in Debian (that's why
cpio-win32 exists, for instance).
S
Reply to: