Re: how to handle architecture dependent headers in subdirectories
Adam Borowski kilobyte at angband.pl writes: This looks just like the solution ultimately chosen for #682183, except for the include being monstrous. Let's instead add a file to libc6-dev with the following: #define DEB_HOST_MULTIARCH x86_64-linux-gnu And then #include DEB_HOST_MULTIARCH /foo/bar.h or what? Is that even valid C? (#include CONFIG_H works in GCC, but…) Also… thinking about this a bit longer… a switch like Doko’s is more correct because, in the M-A case, it’s all about *not* needing to specify the architecture in some file. It’s just divined from the current compiler configuration. I think it has some merit. bye, //mirabilos -- 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/loom.20130117t130453-...@post.gmane.org
Re: how to handle architecture dependent headers in subdirectories
On Thu, 2013-01-17 at 12:06 +, Thorsten Glaser wrote: Adam Borowski kilobyte at angband.pl writes: This looks just like the solution ultimately chosen for #682183, except for the include being monstrous. Let's instead add a file to libc6-dev with the following: #define DEB_HOST_MULTIARCH x86_64-linux-gnu And then #include DEB_HOST_MULTIARCH /foo/bar.h or what? Is that even valid C? It's not standard, nor is it supported in gcc (coincidentally I had a completely different reason to try it yesterday). (#include CONFIG_H works in GCC, but…) That *is* standard, but limited to a single macro. I think gcc also supports use of a function-macro invocation which could do the pasting, but that's non-standard. Ben. Also… thinking about this a bit longer… a switch like Doko’s is more correct because, in the M-A case, it’s all about *not* needing to specify the architecture in some file. It’s just divined from the current compiler configuration. I think it has some merit. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Re: how to handle architecture dependent headers in subdirectories
On Thu, Jan 17, 2013 at 01:21:41PM +, Ben Hutchings wrote: On Thu, 2013-01-17 at 12:06 +, Thorsten Glaser wrote: Adam Borowski kilobyte at angband.pl writes: #define DEB_HOST_MULTIARCH x86_64-linux-gnu And then #include DEB_HOST_MULTIARCH /foo/bar.h or what? Is that even valid C? It's not standard, nor is it supported in gcc (coincidentally I had a completely different reason to try it yesterday). No, it is both blessed by ISO C, and supported by gcc: 6.10.2.2: } # include h-char-sequence new-line 6.10.2.3: } # include q-char-sequence new-line 6.10.2.4 says: } A preprocessing directive of the form } # include pp-tokens new-line } (that does not match one of the two previous forms) is permitted. The } preprocessing tokens after include in the directive are processed just as } in normal text. (Each identifier currently defined as a macro name is } replaced by its replacement list of preprocessing tokens.) The directive } resulting after all replacements shall match one of the two previous } forms. [...] (#include CONFIG_H works in GCC, but…) As required by the above. That *is* standard, but limited to a single macro. You can combine them as you wish, there's just one trick: the #include line _directly_ can include at most one of delimiters, or otherwise it will match 6.10.2.2 or 6.10.2.3 (yes, it is an unintuitive quirk). Also, the behaviour of ## is unclear and might be what the following discussion declares to be implementation specific, but fortunately, it's not needed: #define STDIO stdio #define _H .h #define sysinclude(x) x #include sysinclude(STDIO _H) -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130117155940.ga6...@angband.pl
Re: how to handle architecture dependent headers in subdirectories
On Thu, Jan 17, 2013 at 08:51:34AM +0800, Paul Wise wrote: Would it be possible to use something similar to the bits/ dir in eglibc? Or would your proposal replace that? /usr/include/python2.7/bits - /usr/include/x86_64-linux-gnu/python2.7/bits Not Multi-Arch: same safe. (Note how /usr/include/bits is only shipped by the multi*lib* packages, e.g. libc6-dev-amd64.) -- Colin Watson [cjwat...@debian.org] -- 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/20130117181716.ga27...@riva.dynamic.greenend.org.uk
Re: how to handle architecture dependent headers in subdirectories
On Wed, Jan 16, 2013 at 03:28:53PM -0800, Russ Allbery wrote: Matthias Klose d...@debian.org writes: There are some issues when you do have an architecture dependent header file which needs to be in the multiarch specific include directory. If the header file is directly located in /usr/include, then moving it to /usr/include/multiarch-tuple usually is not a problem (except for quoting issues as found in the packaging for libreoffice). The compilers (checked here GCC and clang) do include the multiarch include path as a path for system includes too. However there are some issues when you do need to split the header files into different locations. Seen that with python2.7 and python3.3 in experimental, however I think it is a concern for packages like openssl as well. Looking at python in experimental (having the architecture independent headers in /usr/include and the architecture dependent headers in /usr/include/multiarch-tuple) you have some build failures. For the python case: - moving all the headers to the multiarch include path doesn't work, because configure tests fail which assume the include directory a direct subdirectory of prefix. Why not just fix this bug instead? Primarily, because the bug needs to be fixed in a large number of separate upstream sources, and until this is done (which is unlikely to happen during the release freeze, even in experimental), improved multiarch support for python headers (which is rather important for cross-buildability of Debian) would be blocked. That's what I did for OpenAFS. I think it's more robust than trying to split the header files apart. This is probably a sign of badly-written configure probes anyway, since it implies that configure is not using the compiler to test headers and is instead poking about on the file system. If all upstream sources were using sensible configure checks (i.e., via pkg-config), then /either/ approach to distributing the headers would work fine. The perverse world we live in gives us instead a range of upstream sources with mutually opposed sets of incorrect build-time checks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: how to handle architecture dependent headers in subdirectories
On Wed, Jan 16, 2013 at 11:32:45PM +0100, Matthias Klose wrote: There are some issues when you do have an architecture dependent header file which needs to be in the multiarch specific include directory. If the header file is directly located in /usr/include, then moving it to /usr/include/multiarch-tuple usually is not a problem (except for quoting issues as found in the packaging for libreoffice). The compilers (checked here GCC and clang) do include the multiarch include path as a path for system includes too. However there are some issues when you do need to split the header files into different locations. So I'm proposing to use a header which can be installed into /usr/include and does include the header file included in a subdirectory installed into /usr/include/multiarch-tuple and works around the issue. Attaching the proposed header file, intending to include it into the gcc package as /usr/lib/gcc/multiarch.h.in #if defined(__linux__) # if defined(__x86_64__) defined(__LP64__) # include x86_64-linux-gnu/@subdir@/@header@ # elif defined(__x86_64__) defined(__ILP32__) # include x86_64-linux-gnux32/@subdir@/@header@ # elif defined(__i386__) # include i386-linux-gnu/@subdir@/@header@ This looks just like the solution ultimately chosen for #682183, except for the include being monstrous. Let's instead add a file to libc6-dev with the following: #define DEB_HOST_MULTIARCH x86_64-linux-gnu (for different values of x86_64-linux-gnu). It might be either a new file on its own, or an addition to one of existing headers. This is currently /usr/include/x86_64-linux-gnu/lua5.1-deb-multiarch.h except that it'd be a pain to do this for every single package. Having a #define that says amd64 could be good, too. Doing it this way would remove a yet another place that has to be changed when adding a new arch. Also, having it as a string allows other uses than a static #include. -- How to squander your resources: those silly Swedes have a sauce named hovmästarsås, the best thing ever to put on cheese, yet they waste it solely on mere salmon. -- 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/20130116232343.ga16...@angband.pl
Re: how to handle architecture dependent headers in subdirectories
Matthias Klose d...@debian.org writes: There are some issues when you do have an architecture dependent header file which needs to be in the multiarch specific include directory. If the header file is directly located in /usr/include, then moving it to /usr/include/multiarch-tuple usually is not a problem (except for quoting issues as found in the packaging for libreoffice). The compilers (checked here GCC and clang) do include the multiarch include path as a path for system includes too. However there are some issues when you do need to split the header files into different locations. Seen that with python2.7 and python3.3 in experimental, however I think it is a concern for packages like openssl as well. Looking at python in experimental (having the architecture independent headers in /usr/include and the architecture dependent headers in /usr/include/multiarch-tuple) you have some build failures. For the python case: - moving all the headers to the multiarch include path doesn't work, because configure tests fail which assume the include directory a direct subdirectory of prefix. Why not just fix this bug instead? That's what I did for OpenAFS. I think it's more robust than trying to split the header files apart. This is probably a sign of badly-written configure probes anyway, since it implies that configure is not using the compiler to test headers and is instead poking about on the file system. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bocog11m@windlord.stanford.edu
Re: how to handle architecture dependent headers in subdirectories
Would it be possible to use something similar to the bits/ dir in eglibc? Or would your proposal replace that? /usr/include/python2.7/bits - /usr/include/x86_64-linux-gnu/python2.7/bits And in /usr/include/python2.7/* #include python2.7/bits/foo.h -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6F7eY2Wjo9W9ao=f8xjpu7oorh2e3uifwy6syvjazs...@mail.gmail.com
