| 1 |
On Sun, 27 Jan 2013 16:12:37 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> 5. Solutions to specific problems |
| 5 |
> --------------------------------- |
| 6 |
> |
| 7 |
> 1. x11-proto packages |
| 8 |
> |
| 9 |
> Those packages install headers to /usr/include and pkg-config files |
| 10 |
> to /usr/lib64. This supposedly means that the headers could be |
| 11 |
> ABI-specific; however, so far I haven't seen a single difference. |
| 12 |
> |
| 13 |
> Possible solutions: |
| 14 |
> |
| 15 |
> a) check the headers by hand, move pkg-config files to /usr/share, |
| 16 |
> |
| 17 |
> b) make the proto packages multilib. This will cause identical .pc |
| 18 |
> files to be installed to lib32 & lib64 but will also enable eclass |
| 19 |
> checks for header consistency. |
| 20 |
|
| 21 |
b) sounds like what we should do by default while lobbying upstream to |
| 22 |
do a) :) |
| 23 |
|
| 24 |
|
| 25 |
> 2. packages which install ABI-dependent headers |
| 26 |
> |
| 27 |
> e.g. libogg. The issue needs to be fixed in the specific ebuild. |
| 28 |
> |
| 29 |
> a) fix the headers, e.g.: |
| 30 |
> |
| 31 |
> typedef short ogg_int16_t; |
| 32 |
> typedef unsigned short ogg_uint16_t; |
| 33 |
> typedef int ogg_int32_t; |
| 34 |
> |
| 35 |
> to: |
| 36 |
> |
| 37 |
> #include <stdint.h> |
| 38 |
> |
| 39 |
> typedef int16_t ogg_int16_t; |
| 40 |
> ... |
| 41 |
> |
| 42 |
> b) install the header(s) in an alternate location. With packages using |
| 43 |
> pkg-config, that would be easy. |
| 44 |
|
| 45 |
b) is not an option: this will break those that do not use pkg-config |
| 46 |
a) is the correct solution, in cooperation with upstream of course, and |
| 47 |
it shouldn't be that hard for the libogg example since, as far as I can |
| 48 |
see, they already have such typedefs for other OSes. |
| 49 |
|
| 50 |
|
| 51 |
> 3. packages which still reinvent pkg-config with their *-config |
| 52 |
> |
| 53 |
> e.g. llvm. Really painful to solve; probably will require action both |
| 54 |
> on llvm ebuild side and consumer side. |
| 55 |
> |
| 56 |
> a) long-term solution: convince upstream to use pkg-config. |
| 57 |
> |
| 58 |
> b) short-term: rename the llvm-config script and use the renamed |
| 59 |
> version for 32-bit build. |
| 60 |
|
| 61 |
yes, but b) is a mess as there will be no generic solution :( |
Archives