On 28/06/14 18:44, Osamu Aoki wrote: > The path for the arch dependent header file seems to have several options. > > 1) /usr/include/<multiarch>/*.h > 2) /usr/include/<multiarch>/<packagename>/*.h > 3) /usr/lib/<multiarch>/<packagename>/include/*.h
The correct answer depends: (a) what users are meant to #include (e.g. <foo.h> vs. <foo/foo.h>) (b) whether users are meant to be able to #include the header from the default include path, or whether they are meant to have to use pkg-config or similar to select one of potentially several incompatible versions <http://ometer.com/parallel.html> (1) is correct if you are meant to include <foo.h> without pkg-config. (2) is correct if you are meant to include <foo/foo.h> without pkg-config, or <foo.h> with -I.../<packagename> provided by pkg-config. (3) is correct if your upstream cares about "lib64"-style bi-arch systems, and is something of a workaround for Debian-style multiarch being relatively new. If "lib64" distributions like Fedora had always had Debian-style multiarch, perhaps it would be /usr/include/<multiarch>/glib-2.0/glibconfig.h; but Debian and its derivatives are the only distros where /usr/include/<multiarch> exists, and upstreams want a solution that works everywhere. I conjecture that there are no significant upstreams that care about multiarch on Debian, but not biarch on Fedora. :-) > (I was looking for the typedef of gsize in gobject header files in > /usr/include/glib-2.0. It tool me time to find it in > /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h) FYI, GLib's "build-time API" is that you use the glib-2.0 pkg-config module, which adds /usr/lib/<multiarch>/glib-2.0/include to the search path; its upstream maintainers would consider anything involving "#include <.../glib-2.0/...>" to be incorrect. gsize is always meant to be the same size as size_t (as checked by configure). GLib has a "no system headers included in our headers" policy to help its portability to systems with non-ISO or non-POSIX headers, so it needs configure checks for gint32 (= int32_t) etc. anyway. size_t doesn't need a header on ISO C systems, but I think GLib might support (or once have supported) environments where size_t doesn't exist and sizeof() returns unsigned or something. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53afdf6a.6080...@debian.org
