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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51912964.9070...@debian.org