| 1 |
On 22/08/13 11:16, Michał Górny wrote: |
| 2 |
> Dnia 2013-08-22, o godz. 10:56:10 |
| 3 |
> Nikos Chantziaras <realnc@×××××.com> napisał(a): |
| 4 |
> |
| 5 |
>> Now that Gentoo is much better in handling multilib libraries, but |
| 6 |
>> Gentoo is source-based, there's the question of which header files are |
| 7 |
>> used between different ABI builds. |
| 8 |
>> |
| 9 |
>> As I understand it, only the headers from the default ABI are installed. |
| 10 |
>> That means that building for abi_x86_32 on a amd64 system will use the |
| 11 |
>> headers installed by the abi_x86_64 build of the used library. |
| 12 |
> |
| 13 |
> The build process installs alls headers by default and compares |
| 14 |
> if they're the same. The ebuild can also specify that some headers need |
| 15 |
> to be wrapped -- in that case they are installed with an ABI-detecting |
| 16 |
> wrapper on top. |
| 17 |
|
| 18 |
Perfect. That's exactly what I wanted to know :-) |
| 19 |
|
| 20 |
|
| 21 |
>> From a developer's point of view, does that mean that we now have to |
| 22 |
>> keep Gentoo in mind when writing header files, or does Gentoo apply any |
| 23 |
>> kind of magic here to fix differences between header files for different |
| 24 |
>> archs? For example, if I need to provide a PTR_SIZE macro in a header |
| 25 |
>> that contains the size of void pointers on this particular system, I |
| 26 |
>> would detect this with autoconf and then just use that, so the header |
| 27 |
>> file would end up simply containing: |
| 28 |
>> |
| 29 |
>> #define PTR_SIZE 8 |
| 30 |
>> |
| 31 |
>> on x86-64, and: |
| 32 |
>> |
| 33 |
>> #define PTR_SIZE 4 |
| 34 |
>> |
| 35 |
>> on x86. The x86-64 header won't work properly when building on Gentoo |
| 36 |
>> for abi_x86_32. As a developer, this is a no-no for me: |
| 37 |
>> |
| 38 |
>> #ifdef THIS_ARCH |
| 39 |
>> #define PTR_SIZE 8 |
| 40 |
>> #elif defined THAT_ARCH |
| 41 |
>> #define PTR_SIZE 4 |
| 42 |
>> ... |
| 43 |
>> |
| 44 |
>> because detection should be done in autoconf, not in the header file. |
| 45 |
> |
| 46 |
> As a developer, you should learn not to put anything system- or machine- |
| 47 |
> -specific in public headers. This is simply wrong, and will break more |
| 48 |
> ways than you could imagine. |
| 49 |
> |
| 50 |
> We're hacking it over but it's far from perfect, and is not an excuse |
| 51 |
> to write more screwed up software. Anything you detect about the host |
| 52 |
> should be used *only* inside C files, and header files that are only |
| 53 |
> used during build-time and not installed. |
| 54 |
|
| 55 |
That's good advice in general, but sometimes this can't be done. C++ |
| 56 |
templates for example need to be in headers, and thus there's sometimes |
| 57 |
gonna be platform-specific stuff in them. Even if the headers are |
| 58 |
private, they still need to be there and will get included indirectly. |
Archives