Hello devs,

I'm currently adding ppc64le to the list of platforms supported by
icedtea-bin before we lose gcj to save me fudging around later. This
addition presents a small problem.

I currently use the ARCH (e.g. amd64) and ABI (e.g. abi_x86_32) USE
flags to fetch the relevant tarballs. The trouble is that there is no
flag that decides the endianness. Both ppc64 and ppc64le share the
"ppc64" ARCH and ABI. The only differing element between the two
profiles is CHOST, which starts with powerpc64- and powerpc64le-
respectively.

This is sufficient when dealing with multilib-enabled source ebuilds.
As far as I know, there is no such as thing as a mixed endian system on
any architecture. They require different kernels. If a package doesn't
work on one endian type, it can simply be masked in that profile.

However, when dealing with binary ebuilds, you ideally want to split
the different platforms into separate tarballs to reduce the download
size. The platform-specific tarballs for icedtea-bin:8 currently weigh
around 55MB each. It would be polite not to double this for ppc64. You
can't use CHOST in SRC_URI so a new USE flag is the only way.

I am therefore proposing a new global big-endian flag. This could be
masked by default and unmasked + forced in the relevant profiles under
arch. I will apply this according to the mapping defined in tc-endian of
toolchain-funcs.eclass.

There is just one package already this flag, dev-haskell/skein. I don't
believe it would need to change though it might want to hard enable the
force-endianness option or at least enable it by default. On the other
hand, using tc-endian may be a better option here.

If we're broadly agreed then I will submit a patch for review.

On a side note, this problem also applies to soft vs hard float except
that these can be mixed under the same kernel. We don't have profiles
for these though and soft float seems to be a relic now anyway, at
least on ARM.

Cheers,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Attachment: pgpd5ujrDlhPv.pgp
Description: OpenPGP digital signature

Reply via email to