Hello, I’m using a ubuntu jaunty host for openembedded and angstrom 2008.1
Everything works fine so far, bitbake console-image and other tests run fine on the beagleboard
Now I would like to test some apps in another computer also with ubuntu before I create a recipe and put it below my local repository.
After some reading I understood I need to get a cross-compiler in the other computer, and the task meta-toolchain would do the job, so I just ran
bitbake meta-toolchain and got two packages under tmp/deploy/glibc/sdk :
angstrom-2009.X-test-20091013-armv7a-linux-gnueabi-toolchain-extras.tar.bz2
angstrom-2009.X-test-20091013-armv7a-linux-gnueabi-toolchain.tar.bz2
I copied and uncompressed both in my other computer, I sourced the environment-setup script and I tried to compile some programs.
The trouble comes when the compiler tries to find “as” the assembler which is not in any of those two packages
I looked it up in the openembedded host and I found it below :
tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-as
Shouldn’t it be also in the meta-toolchain result packages? How do you get a complete cross-compiling environment out of the openembedded and bitbake tree?
Is it better to get a third party toolchain for the beagleboard?
Am I missing some bitbake task?
Hello, I'm using a ubuntu jaunty host for openembedded and angstrom 2008.1
Everything works fine so far, bitbake console-image and other tests run
fine on the beagleboard
Now I would like to test some apps in another computer also with ubuntu
before I create a recipe and put it below my local repository.
Could you please explain your use-case? I have trouble understanding why you
think you need to do this instead of just creating a recipe for it.
Recipe's are great for working software, but while developing
software, it is nice to have an independent toolchain you can use
outside OE.
For example, I am procrastinating real work, by using task-native-sdk
on teh beagle to compile fftw on the beagle. This appears to work So I
can use familiar processes to investigate adding NEON support to fftw.
(Turns out the first thing I need to do is read the cycle counters).
For more involved projects, I have used configure to use the toolchain
and libraries from OE staging, however this requires you do an OE
build first .
Finally, you can extract toolchains from OE, but I suspect these might
not run well on machines that a different from the machine you built
them on.
I need to be able to test the software outside of OE for the initial states when lots of trial and error are done.
And another reason is that I’m not a very experienced programmer, bitbake hides all the underlying complexity of libraries and includes which is good when things work but its a pain when they don’t.
So I see bitbake as a perfect solution for deploying once my software is fully tested but in the initial states I just don’t see it.
I can see that use case, but in my experience trying to get it working without OE first just makes you solve the same problems twice, instead of killing 2 birds with one stone.
Maybe other people like wasting time, but I don’t
>>
>> Hello, I'm using a ubuntu jaunty host for openembedded and angstrom
>> 2008.1
>> Everything works fine so far, bitbake console-image and other tests run
>> fine on the beagleboard
>> Now I would like to test some apps in another computer also with ubuntu
>> before I create a recipe and put it below my local repository.
>
> Could you please explain your use-case? I have trouble understanding why
> you
> think you need to do this instead of just creating a recipe for it.
Recipe's are great for working software, but while developing
software, it is nice to have an independent toolchain you can use
outside OE.
I can see that use case, but in my experience trying to get it working
without OE first just makes you solve the same problems twice, instead of
killing 2 birds with one stone.
Maybe other people like wasting time, but I don't
One issue using external toolchains is that the autotools stuff
sometimes does generate working makefiles' for cross compiling. In OE
we have some site files containing overrides for autoconf tests. Also,
if a test picks up host libraries and includes, we can sed the
Makefiles accordingly
However, doing to cross work stand alone, may reduce the number of
problems we need to fix in the recipe.
