Re: multiarch: arch dependent header file path choice
Am 28.06.2014 19:44, schrieb Osamu Aoki: Hi, 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 I would like to know rationale for each choice, especially between 2 and 3. 1) has the advantage that it is found in the standard include path. 3) is a cheap work around for packages installing everything into a common prefix and then either providing symlinks in other places or forcing users to rely on pkg-config or other methods to find files. You are missing 1b) /usr/include/packagename/*.h There should almost be no issues for packages putting header files directly in /usr/include or /usr/include/multiarch. Yes, there are some dumb tests checking for the existence of files in a certain path which will break. Packages installing header files in /usr/include/packagename usually need a knowledge of the include path, and you'll break things just moving all header files or a part of it to /usr/include/multiarch/packagename, because depending packages expect that only one include path is sufficient. The solution here is to use a fake header in /usr/include/packagename which includes the appropriate header in /usr/include/multiarch/packagename. python2.7's and python3.4's pyconfig.h file is such an example. But even here you find configure checks to grep pyconfig.h for certain features which break which such kind of setup ... and of course it needs updates for new architectures. I am sure they all are functioning choice but intriguing to see choice 3. (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) this doesn't seem to conform to the FHS, and I assume a FHS conformant packaging wouldn't make things worse. As I look around on my system, I observe followings For 1, *.h are: expat_config.h ffi.h ffitarget.h one of them can live in /usr/include, however I personally prefer to install header files in one location. fpu_control.h gmp.h this is an example where the upstream header was patched to co-install on 32/64 bit systems not knowing about multiarch. ieee754.h lua5.1-deb-multiarch.h lua5.2-deb-multiarch.h zconf.h For 2, packagename are python3.3m see above for the explanation for python. openssl ruby-2.0.0 c++ this is in the standard c++ include path, so it doesn't need any special configury. ... For 3, packagename are: glib-2.0 gtk-2.0 gtk-3.0 dbus-1.0 (dbus/dbus-arch-deps.h as *.h) what a surprise ... I assume many upstream developers are working for distros not using multiarch. Matthias -- 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/53b5cbce.8050...@debian.org
Re: multiarch: arch dependent header file path choice
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
multiarch: arch dependent header file path choice
Hi, 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 I would like to know rationale for each choice, especially between 2 and 3. I am sure they all are functioning choice but intriguing to see choice 3. (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) As I look around on my system, I observe followings For 1, *.h are: expat_config.h ffi.h ffitarget.h fpu_control.h gmp.h ieee754.h lua5.1-deb-multiarch.h lua5.2-deb-multiarch.h zconf.h For 2, packagename are python3.3m openssl ruby-2.0.0 c++ ... For 3, packagename are: glib-2.0 gtk-2.0 gtk-3.0 dbus-1.0 (dbus/dbus-arch-deps.h as *.h) Regards, Osamu -- 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/20140628174421.GA19782@goofy
Re: multiarch: arch dependent header file path choice
On Sun, Jun 29, 2014 at 02:44:21AM +0900, Osamu Aoki wrote: Hi, 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 I would like to know rationale for each choice, especially between 2 and 3. Choice 1 is just the default location for most headers. Choice 2 is useful if you have multiple versions of the same library. For example, you might want to have the headers for Ruby 2.0 and Ruby 2.1 installed at the same time. They're going to ship mostly the same headers, so putting them in different directories allows them to be co-installable. Some upstreams prefer this location. Choice 3 is for private header files. Most of Glib's headers are of style 2, but it ships one file, which is autogenerated, in this location because it's only intended to be called from other Glib header files. This method is used because on distributions like CentOS that don't have multiarch, these private header files often contain arch-dependent configuration, so they are placed in /usr/lib or /usr/lib64 as appropriate so that the 32-bit and 64-bit packages are co-installable. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
