Re: [nslu2-linux] Re: Endian-ness (was Looking for include files)
- Charles Lindsey wrote:
> --- In email@example.com, "Mike (mwester)" <mwester@...> wrote:See http://www.nslu2-linux.org/wiki/Development/MasterMakefile -- the
>> So, help me understand your situation a bit, then:
>> Are you saying that "gcc x.c" does not create an "a.out" that can
>> actually be executed on the host system?
>> What exactly did you install, so that we can look at the packages in
>> question and see what's going on?
> I haven't installed anything yet. I am in porcess of setting up a cross compiler, and
> I had a look at Crosstool, and found it did not do exactly what I wanted, but it
> gave lots of useful hints as to how to configure and build what I needed.
>> (And just for background, the lack of response on this is probably
>> because compiling and building on the NSLU2 itself is extraordinarily
>> rare; the device just doesn't have enough RAM to make it practical.)
> No, I am building a cross-compiler, not a native one.
only supported way (currently) to get a cross-compiler built for Unslung
>>>> Sadly, noone has replied to this, but I have now managed to put together whatMike (mwester)
>>>> seems to be a proper set of #include files from the source of glibc-2.5.
>> Where did you get these? Might it be that these files don't match, and
>> that is a source of at least some of the current troubles?
> I downloaded the source for glibc 2.5, which appeared to be the version
> slugos-be-4.8 was using, configured it in what seemed to be the proper
> way, and did 'gnumake install- headers'. I did not want to go through the
> hassle of recompiling the complete library, because that was already available
> in the slugos distribution, and you can do install-headers without having to
> make an intermediate 'core' cros cross-compiler like Crosstool does.
> Here, for the record, is my 'configure' call:
> /bigspare/glibc-2.5/configure --enable-add-ons=/bigspare/glibc-ports-2.5\
> --prefix=/tmp --build=sparc-sun-solaris2.10 --host=arm-slug-linux --without-cvs\
> --disable-profile --disable-debug --without-gd
> I then examined the header files it had produced, and in particular endian.h,
> and it became apparent that it expected __ARMEB__ to have been #defined
> by the compiler, and greping for __ARMEB__ in the gcc source showed that
> it would indeed define that if given the proper flag, which the manpage claimed
> to be '-m big-endian'. And indeed, this was confirmed by trying
> 'xgcc --help-target' on the trial compilation of gcc that I had already made.
>> The cross-compiler absolutely knows what it is compiling for - there are
>> completely unique toolchains built for LE vs BE cross builds. And the
>> native toolchains are likewise unique for the two.
> Well yes, that it what I was expecting the cross-compiler to be like. But
> nowhere in the READMEs for Crosstool, or for gcc, or for glibc could I
> find any flags that should be given to 'configure' to make it so. Note that
> I was trying to build gcc version 3.4.3, because that is the version bundled
> with my operating system, and I did not want to be worrying about different
> versions of gcc for different targets.
> And, in fact, there may be some advantage in using the compile-time flag
> '-m big-endian', since I have a further possible arn-based project comping up
> involving a different board with a different arm chip and most likely little-endian,
> and it would be simpler to build a generic arm cross-compiler rather than to
> generate a separate cross-compiler for each project. Anyway, I expect to
> have my corss-build completed in the next day or so, and I will report
> progress here. It shold be a simple matter to hide those special flags
> inside suitablem wrapper scripts for the two projects.
>> SlugOS/BE runs in big-endian, from bootloader to kernel to user-space.
>> SlugOS/LE boots in big-endian, then the secondary bootloader switches
>> the device into LE mode, and the kernel and userspace run in LE. It is
>> not possible to mix LE and BE code in the same system.
> Yes, that is what I expected to be the situation.
>>> It also appears that one should set the '-mcpu-xscale' flag for any Slug compilation.
>>> Are there any other ARM-specific flags that I am likely to need?
>> You should have to do nothing to make it work correctly. Any particular
>> "tuning" flags would be package-specific, and merely amount to "hints"
>> to the optimizer and code generator to help them create final code that
>> is optimal for the underlying hardware. In other words, "gcc x.c" is
>> sufficient to create a functioning executable; anything else is tuning.