insmod broken in 1.1.1

[Robert P. J. Day]

On Fri, 24 Mar 2006, Bernhard Fischer wrote:

> On Fri, Mar 24, 2006 at 07:50:50PM +0100, stephane.billiart wrote:
> >I tried to upgrade my system today with busybox and realized
> >that insmod systematically fails with the messages:
> >insmod: ELF file not for this architecture
> >insmod: Could not load the module: Success
> >
> >I added some debug output and saw that the error comes from
> >line 3334 of modutils/insmod.c because of ELFDATAM is
> >wrongly set on line 519 because BB_LITTLE_ENDIAN is
> >not defined (although I am on a P3 compiling for an Elan processor
> >which are little endians).
> >
> >I haven't looked at how BB_LITTLE_ENDIAN is supposed to be
> >calculated but there's apparently something wrong there.
> >I am not sure how to best fix this so I'm asking the list first.
> >
> >In 1.1.0 everything worked ok and the test was
> >#if __BYTE_ORDER == __LITTLE_ENDIAN
>
> This was broken by Robert P. J. Day and apparently ci by Rob:
> http://busybox.net/lists/busybox/2006-March/019043.html
>
> Robert, this has come up before, iirc, but i don't seem to see a
> patch which corrects this?

ok, here's what i've found.  (for the record, the patch i submitted
was very much a cut-and-paste that shouldn't have broken anything that
didn't already work.  that's the theory, anyway.)

from what i understood originally, endian-ness is defined in
include/platform.h, but if you look at that file, it defines *only*
the macro BB_BIG_ENDIAN, *not* BB_LITTLE_ENDIAN, which suggests that
*all* tests must be done WRT to BB_BIG_ENDIAN *only*.

in fact, in the entire BB source tree, there is only one source file
that tests against BB_LITTLE_ENDIAN, and that's (you guessed it)
insmod.c.

we can either reverse the test in insmod.c, or enhance platform.h to
define *both* macros.  thoughts?

rday