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

Re: Setup a cross compile envrionment

Expand Messages
  • desaijay84
    Thanks Allan and John. I ll give it a shot! Jimmy ... is that ... almost ... environment ... it limits ... server and ... next to ... need to add ... length of
    Message 1 of 10 , Jun 1, 2005
    • 0 Attachment
      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...>
    • desaijay84
      Hi, I tried to compile from the sources of the beta release. It starts to compile but breaks 5 minutes into the build. When it starts, it generates the
      Message 2 of 10 , Jun 2, 2005
      • 0 Attachment
        Hi,

        I tried to compile from the sources of the beta release. It starts
        to compile but breaks 5 minutes into the build. When it starts, it
        generates the following errors:

        (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
        NOTE: Handling BitBake files: - (0238/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-mm4.bb
        NOTE: Parsing finished. 0 cached, 464 parsed, 21 skipped, 0 masked.

        But it continues to work after this. It then breaks when working with
        the libtool-native-1.5.10-r1 package. The "task do_compile" starts and
        then breaks. I checked the log message, the last few lines are:

        checking whether build environment is sane... yes
        checking for gawk... gawk
        checking whether make sets $(MAKE)... yes
        configure: error: source directory already configured; run "make
        distclean" there first
        make[2]: *** [i686-linux-libtool] Error 1
        make[2]: Leaving directory
        `/home2/arise/nslu2/openslug/tmp/work/libtool-native-1.5.10-r1/libtool-1.5.10'
        make[1]: *** [all-recursive] Error 1
        make[1]: Leaving directory
        `/home2/arise/nslu2/openslug/tmp/work/libtool-native-1.5.10-r1/libtool-1.5.10'
        FATAL: oe_runmake failed

        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.

        Any ideas as to what is going wrong?

        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 ... .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 3 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 4 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 5 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 6 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 7 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.