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

Setup a cross compile envrionment

Expand Messages
  • desaijay84
    Hi, 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
    Message 1 of 10 , May 31, 2005
      Hi,

      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 and found some for Unslung - relating to Dan
      Kegel's cross compile script. I tried to apply that for Openslug but
      unfortnately I couldn't get it right and the build broke midway.

      Has anybody successfully built a cross compilers for this case?
      Your help would be very much appreciated.

      Thanks,
      Jimmy
    • m. allan noah
      jimmy, openslug builds its own cross-compile environment as a part of building the image. just follow the openslug instructions on the wiki (the stuff that
      Message 2 of 10 , May 31, 2005
        jimmy, openslug builds its own cross-compile environment as a part of
        building the image. just follow the openslug instructions on the wiki (the
        stuff that talks about openembedded and bitbake, etc)

        once you get that up and working, you can use the existing infrastructure
        to make any mods you need.

        need help? ask on irc.

        allan

        On Tue, 31 May 2005, desaijay84 wrote:

        > Hi,
        >
        >    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 and found some for Unslung - relating to Dan
        > Kegel's cross compile script. I tried to apply that for Openslug but
        > unfortnately I couldn't get it right and the build broke midway.
        >
        >    Has anybody successfully built a cross compilers for this case?
        > Your help would be very much appreciated.
        >
        > Thanks,
        > Jimmy
        >
        >
        >
        >
        >
        >
        > [ Moderator Note: All new information should be recorded in the Wiki at
        > http://www.nslu2-linux.org ]
        >
        >
        > ________________________________________________________________________________
        > Yahoo! Groups Links
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/nslu2-linux/
        >  
        > * To unsubscribe from this group, send an email to:
        > nslu2-linux-unsubscribe@yahoogroups.com
        >  
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        >
        >

        --
        "so don't tell us it can't be done, putting down what you don't know.
        money isn't our god, integrity will free our souls" - Max Cavalera
      • John Bowler
        From: desaijay84 ... 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
        Message 3 of 10 , May 31, 2005
          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@...>
        • 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 4 of 10 , Jun 1, 2005
            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 5 of 10 , Jun 2, 2005
              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 6 of 10 , Jun 2, 2005
                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 7 of 10 , Jun 8, 2005
                  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 8 of 10 , Jun 9, 2005
                    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 9 of 10 , Jun 9, 2005
                      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 10 of 10 , Jun 9, 2005
                        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.