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

RE: [nslu2-linux] Re: Setup a cross compile envrionment

Expand Messages
  • John Bowler
    From: desaijay84 ... .bb This means that somehow you have a more up-to-date version of bitbake than the source files. ... The two nslu2-kernel .bb files were
    Message 1 of 10 , Jun 2, 2005
    • 0 Attachment
      From: desaijay84
      >(source setup-env ; bitbake openslug-packages)
      >Environment set up for OpenSlug development.
      >NOTE: Using cache in '/home/arise/nslu2/openslug/tmp/cache'
      >NOTE: Handling BitBake files: / (0237/0487) [48 %]ERROR: setVar()
      >takes exactly 3 arguments (2 given) while parsing
      >/home/arise/nslu2/openslug/nslu2-linux/packages/linux/nslu2-kernel_2.6.11.8
      .bb

      This means that somehow you have a more up-to-date version of bitbake than
      the source files.

      >NOTE: Parsing finished. 0 cached, 464 parsed, 21 skipped, 0 masked.

      The two nslu2-kernel .bb files were ignored (normally there would be 466
      parsed.) That doesn't matter, the openslug build doesn't use those kernels.

      >I'm running this compile on Debian Sarge with plenty of power and RAM.
      >I've also got all the packages (the ones mentioned on the page for how
      >to compile openslug from repos) installed.

      *Uninstall* bitbake. I believe Python is picking up the site-packages files
      from your bitbake installation. Alternatively you could do "svn up -r154"
      in the directory from which you installed bitbake and re-install - this will
      cause it to go back to rev 154, which is the one required to build
      OpenSlug-1.12-beta.

      I recommend against installing bitbake because of this problem - it's too
      easy to get the wrong version. I think it may also be possible to avoid the
      problem by setting the Python search path (as opposed to BBPATH, which only
      gets used after the wrong bitbake python scripts have been loaded.)

      John Bowler <jbowler@...>
    • desaijay84
      Hey, Everything finaly finished compiling - phew! My main interest is in the cross-compiler, so I was going through the tmp/cross directory. In that, I went
      Message 2 of 10 , Jun 8, 2005
      • 0 Attachment
        Hey,


        Everything finaly finished compiling - phew! My main interest is in
        the cross-compiler, so I was going through the "tmp/cross" directory.
        In that, I went to the armeb-linux directory. That directory looks
        familiar with the bin, include (with all the .h files) and lib.

        But in the tmp/cross directory, there is a bin folder in which there
        is "armeb-linux-g++". So I was a little bit confused. Which one am I
        supposed to use? In addition, back in the tmp/cross folder, there are
        more folders, "lib" (doesn't have all the .h files that are in the
        tmp/cross/armeb-linux/include/; it also has a sub-folder armeb-linux),
        "libexec", "man" (man has two more subdirectories but are empty), etc.
        I was just wondering which ones to use.

        When I tried to compile using the g++ in tmp/cross/armeb-linux/bin,
        it complained about not being able to find cclplus. But I saw that a
        located inside the tmp/cross/libexec folder.

        So I was wondering if somebody could give me a quick idea of how to
        set it up. Or if there exists some documentation on it, could you
        please point me to it?

        Thanks,
        Jimmy


        --- In nslu2-linux@yahoogroups.com, "desaijay84" <desaijay84@y...>
        wrote:
        > Thanks Allan and John. I'll give it a shot!
        >
        > Jimmy
        >
        > --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@a...>
        wrote:
        > > From: desaijay84
        > > > I have been trying to set up a cross compiler (GCC 3.4, for C
        and
        > > >C++) for NSLU2 (for Openslug) but I've had no luck. I looked for
        > > >information on the Wiki
        > >
        > > We need to update the OpenSlug home page I think to make it into
        an
        > > introduction. This is an understandable question to ask, my guess
        > is that
        > > you are working from a binary OpenSlug download. In this case you
        > almost
        > > certainly want one of the other two options.
        > >
        > > There are three different ways of getting started with OpenSlug:
        > >
        > > 1) Download and flash the binary image from www.openslug.org.
        > > 2) Download the source 'tarball' from www.openslug.org to a
        machine with
        > > disk space, a reasonably powerful CPU and a native development
        > environment
        > > (a C compiler and tools). Build openslug.
        > > 3) Obtain a copy of BitKeeper and appropriate tools, pull the
        whole
        > > OpenEmbedded source from nslu2-linux.bkbits.net and build
        openslug.
        > >
        > > Those three different approaches give the same end-result - an
        openslug
        > > binary - but the different routes allow you to do different
        things.
        > >
        > > (1) is quickest, most reliable and easiest to understand. However
        > it limits
        > > you to installing pre-built packages. If you want a small quiet
        > server and
        > > the available packages offer the services you need then it just
        works,
        > > there's no need for anything else. In this respect it's like the
        stock
        > > LinkSys NSLU2 and Unslung, but it's much more minimal (i.e. it
        does
        > next to
        > > nothing *unless* you install extra stuff!)
        > >
        > > (2) Gives the binary (identical to the release binary) from the
        source.
        > > Consequently it provides a full cross-build environment. If you
        > need to add
        > > your own programs this gets you up and running in a few hours (the
        > length of
        > > time it takes to build from the source.) Pre-built packages
        install
        > fine
        > > from the OpenSlug feed but you can write and add your own.
        > >
        > > (3) Gives the latest, unstable, untested, version of OpenSlug. It
        > may well
        > > not work. Attempting to install packages from the feed is
        probably
        > a bad
        > > idea. Possibly the only reasons for doing this are if there is a
        > bug in the
        > > current released source which prevents you doing something or if
        you are
        > > regularly contributing stuff to the OpenSlug development.
        > >
        > > -------------------
        > >
        > > I just wrote that into this email. I think it's all correct ;-)
        I
        > think
        > > something like this is essential for the OpenSlug homepage (i.e.
        the
        > thing
        > > the www.openslug.org link points to.)
        > >
        > > John Bowler <jbowler@a...>
      • John Bowler
        From: desaijay84 ... And bin/gcc ... and bin/armeb-linux-gcc (the armeb-linux prefix will be armeb-linux-uclibc or something like that on a uclibc build). ...
        Message 3 of 10 , Jun 9, 2005
        • 0 Attachment
          From: desaijay84
          > Everything finaly finished compiling - phew! My main interest is in
          >the cross-compiler, so I was going through the "tmp/cross" directory.
          >In that, I went to the armeb-linux directory. That directory looks
          >familiar with the bin, include (with all the .h files) and lib.

          And bin/gcc

          > But in the tmp/cross directory, there is a bin folder in which there
          >is "armeb-linux-g++".

          and bin/armeb-linux-gcc (the armeb-linux prefix will be armeb-linux-uclibc
          or
          something like that on a uclibc build).

          >So I was a little bit confused. Which one am I supposed to use?

          Mysterious isn't it. I have found that it doesn't matter - I can use
          ../armeb-linux/bin/gcc or I can use ../bin/armeb-linux-gcc and they
          both seem to work just as well as the other. Indeed they may be
          identical - I haven't checked.

          >In addition, back in the tmp/cross folder, there are
          >more folders, "lib" (doesn't have all the .h files that are in the
          <tmp/cross/armeb-linux/include/; it also has a sub-folder armeb-linux),
          >"libexec", "man" (man has two more subdirectories but are empty), etc.
          >I was just wondering which ones to use.

          When using gcc it finds all the headers and libraries correctly (that is
          to say both gcc and armeb-linux-gcc do). No additional setup, no -I and
          no -L are required.

          > When I tried to compile using the g++ in tmp/cross/armeb-linux/bin,
          >it complained about not being able to find cclplus. But I saw that a
          >located inside the tmp/cross/libexec folder.

          I have just built openslug-packages. I wrote a program foo.cpp in a
          directory 'test' such that my 'tmp' directory is ../openslug:

          #include <iostream>
          int main(void) {
          std::cout << "hello wood\n";
          return 0;
          }

          (I admit that's a horrible mixture of C and C++ ;-) I was able to compile
          (and link) this using either of the commands:

          ../openslug/cross/armeb-linux/bin/g++ -o foo foo.cpp
          ../openslug/cross/bin/armeb-linux-g++ -o foo foo.cpp

          I also added the cross/armeb-linux/bin directory to my PATH and was able to
          use "g++" to compile succesfully.

          Clearly the cross tools have the paths compiled in, the only thing I can
          think
          which would break that is if the 'tmp' directory was moved after the build.

          John Bowler <jbowler@...>
        • desaijay84
          Hey, ... After reading your post, I managed to figure out why it would complain about cclplus. The Openslug source was compiled on one machine and I later
          Message 4 of 10 , Jun 9, 2005
          • 0 Attachment
            Hey,

            > Clearly the cross tools have the paths compiled in, the only thing I
            >can think which would break that is if the 'tmp' directory was moved
            >after the build.

            After reading your post, I managed to figure out why it would complain
            about cclplus. The Openslug source was compiled on one machine and I
            later copied over the result to my computer. And so when I would try
            and run the cross-compilation on my computer - it would complain (
            even though the relative directory structure is the same). But when I
            tried to cross-compile on the original computer, it ran perfectly.

            As you mentioned, the paths seems to get hard-coded. Is there a way
            to adjust that? It would be nice if I didn't have to run the complete
            compilation process on every computer on which I need the cross-compiler.

            Thanks a whole bunch!

            Jimmy

            --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@a...> wrote:
            > From: desaijay84
            > > Everything finaly finished compiling - phew! My main interest is in
            > >the cross-compiler, so I was going through the "tmp/cross" directory.
            > >In that, I went to the armeb-linux directory. That directory looks
            > >familiar with the bin, include (with all the .h files) and lib.
            >
            > And bin/gcc
            >
            > > But in the tmp/cross directory, there is a bin folder in which there
            > >is "armeb-linux-g++".
            >
            > and bin/armeb-linux-gcc (the armeb-linux prefix will be
            armeb-linux-uclibc
            > or
            > something like that on a uclibc build).
            >
            > >So I was a little bit confused. Which one am I supposed to use?
            >
            > Mysterious isn't it. I have found that it doesn't matter - I can use
            > ../armeb-linux/bin/gcc or I can use ../bin/armeb-linux-gcc and they
            > both seem to work just as well as the other. Indeed they may be
            > identical - I haven't checked.
            >
            > >In addition, back in the tmp/cross folder, there are
            > >more folders, "lib" (doesn't have all the .h files that are in the
            > <tmp/cross/armeb-linux/include/; it also has a sub-folder armeb-linux),
            > >"libexec", "man" (man has two more subdirectories but are empty), etc.
            > >I was just wondering which ones to use.
            >
            > When using gcc it finds all the headers and libraries correctly (that is
            > to say both gcc and armeb-linux-gcc do). No additional setup, no -I and
            > no -L are required.
            >
            > > When I tried to compile using the g++ in tmp/cross/armeb-linux/bin,
            > >it complained about not being able to find cclplus. But I saw that a
            > >located inside the tmp/cross/libexec folder.
            >
            > I have just built openslug-packages. I wrote a program foo.cpp in a
            > directory 'test' such that my 'tmp' directory is ../openslug:
            >
            > #include <iostream>
            > int main(void) {
            > std::cout << "hello wood\n";
            > return 0;
            > }
            >
            > (I admit that's a horrible mixture of C and C++ ;-) I was able to
            compile
            > (and link) this using either of the commands:
            >
            > ../openslug/cross/armeb-linux/bin/g++ -o foo foo.cpp
            > ../openslug/cross/bin/armeb-linux-g++ -o foo foo.cpp
            >
            > I also added the cross/armeb-linux/bin directory to my PATH and was
            able to
            > use "g++" to compile succesfully.
            >

            >
            > John Bowler <jbowler@a...>
          • John Bowler
            From: desaijay84 ... The standard approach is to mount a common build system somewhere which works on every system, e.g. you might use /shared/openembedded .
            Message 5 of 10 , Jun 9, 2005
            • 0 Attachment
              From: desaijay84
              > As you mentioned, the paths seems to get hard-coded. Is there a way
              >to adjust that? It would be nice if I didn't have to run the complete
              >compilation process on every computer on which I need the cross-compiler.

              The standard approach is to mount a common build system somewhere which
              works on every system, e.g. you might use "/shared/openembedded". Most of
              the time this can also be achieved using symbolic links, but some things in
              the bitbake world seem to resolve out symbolic links, resulting in the full
              path (particularly annoying if you use automount). Still you can use
              symbolic links to make the full path in the executable point back to the new
              place, just uses strings to find out what it's using.

              It is also possible to hand edit the strings, at least it is with modern
              versions of vi (etc) which don't mind editting files with very long lines
              and null characters. So long as you don't change the length (/././././.) it
              will still work. I'd recommend the first approach ;-)

              John Bowler <jbowler@...>
            Your message has been successfully submitted and would be delivered to recipients shortly.