| 1 |
On Wed, 28 Jun 2017 17:52:26 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot <chewi@g.o> wrote: |
| 5 |
> > I am therefore proposing a new global big-endian flag. This could be |
| 6 |
> > masked by default and unmasked + forced in the relevant profiles under |
| 7 |
> > arch. I will apply this according to the mapping defined in tc-endian of |
| 8 |
> > toolchain-funcs.eclass. |
| 9 |
|
| 10 |
I've just been putting the patch together. I made it slightly simpler |
| 11 |
by masking *and* forcing it by default so that it only needs to be |
| 12 |
unmasked were necessary. |
| 13 |
|
| 14 |
> A possible alternative would be to create a new USE_EXPAND variable |
| 15 |
> for this. That would allow for easier expansion in case we ever |
| 16 |
> support something other than big/little endian machines. |
| 17 |
|
| 18 |
That way madness lies? Wikipedia talks about middle-endian as being the |
| 19 |
catch all for other random orderings that have appeared over the years |
| 20 |
but I don't think any of them were used on a system-wide basis. I can't |
| 21 |
imagine Linux ever supporting such a thing. Unless you're talking about |
| 22 |
dealing with soft vs hard float here too? |
| 23 |
|
| 24 |
-- |
| 25 |
James Le Cuirot (chewi) |
| 26 |
Gentoo Linux Developer |
Archives