| 1 |
Hello devs, |
| 2 |
|
| 3 |
I'm currently adding ppc64le to the list of platforms supported by |
| 4 |
icedtea-bin before we lose gcj to save me fudging around later. This |
| 5 |
addition presents a small problem. |
| 6 |
|
| 7 |
I currently use the ARCH (e.g. amd64) and ABI (e.g. abi_x86_32) USE |
| 8 |
flags to fetch the relevant tarballs. The trouble is that there is no |
| 9 |
flag that decides the endianness. Both ppc64 and ppc64le share the |
| 10 |
"ppc64" ARCH and ABI. The only differing element between the two |
| 11 |
profiles is CHOST, which starts with powerpc64- and powerpc64le- |
| 12 |
respectively. |
| 13 |
|
| 14 |
This is sufficient when dealing with multilib-enabled source ebuilds. |
| 15 |
As far as I know, there is no such as thing as a mixed endian system on |
| 16 |
any architecture. They require different kernels. If a package doesn't |
| 17 |
work on one endian type, it can simply be masked in that profile. |
| 18 |
|
| 19 |
However, when dealing with binary ebuilds, you ideally want to split |
| 20 |
the different platforms into separate tarballs to reduce the download |
| 21 |
size. The platform-specific tarballs for icedtea-bin:8 currently weigh |
| 22 |
around 55MB each. It would be polite not to double this for ppc64. You |
| 23 |
can't use CHOST in SRC_URI so a new USE flag is the only way. |
| 24 |
|
| 25 |
I am therefore proposing a new global big-endian flag. This could be |
| 26 |
masked by default and unmasked + forced in the relevant profiles under |
| 27 |
arch. I will apply this according to the mapping defined in tc-endian of |
| 28 |
toolchain-funcs.eclass. |
| 29 |
|
| 30 |
There is just one package already this flag, dev-haskell/skein. I don't |
| 31 |
believe it would need to change though it might want to hard enable the |
| 32 |
force-endianness option or at least enable it by default. On the other |
| 33 |
hand, using tc-endian may be a better option here. |
| 34 |
|
| 35 |
If we're broadly agreed then I will submit a patch for review. |
| 36 |
|
| 37 |
On a side note, this problem also applies to soft vs hard float except |
| 38 |
that these can be mixed under the same kernel. We don't have profiles |
| 39 |
for these though and soft float seems to be a relic now anyway, at |
| 40 |
least on ARM. |
| 41 |
|
| 42 |
Cheers, |
| 43 |
-- |
| 44 |
James Le Cuirot (chewi) |
| 45 |
Gentoo Linux Developer |
Archives