Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] Re: Endian-ness (was Looking for include files)

Expand Messages
  • Mike (mwester)
    ... See http://www.nslu2-linux.org/wiki/Development/MasterMakefile -- the only supported way (currently) to get a cross-compiler built for Unslung or SlugOS.
    Message 1 of 6 , Jan 19, 2009
    • 0 Attachment
      Charles Lindsey wrote:
      > --- In nslu2-linux@yahoogroups.com, "Mike (mwester)" <mwester@...> wrote:
      >> 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.

      See http://www.nslu2-linux.org/wiki/Development/MasterMakefile -- the
      only supported way (currently) to get a cross-compiler built for Unslung
      or SlugOS.

      >>>> Sadly, noone has replied to this, but I have now managed to put together what
      >>>> 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.

      Mike (mwester)
    Your message has been successfully submitted and would be delivered to recipients shortly.