OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: Meanie on September 21, 2006, 09:45:17 am
-
I build a cramfs image with a working gcc and g++ compiler so that you can just mount the image and start compiling stuff on the Zaurus.
I have found that simply installing gcc and related packages wont give you a working c compiler. I had to tweak several environment variables and create a few extra symbolic links to get it all working.
At the moment, I can compile helloworld, but I am working on adding more dev packages so that the image will be ready to use for building X applications similar to the gcc compiler image in pdaXrom. I have build a shell script to automate building this gcc cramfs image. With this image I will be able to recompile some apps and compile new ones with iwmmxt optimisations.
-
I have found that simply installing gcc and related packages wont give you a working c compiler. I had to tweak several environment variables and create a few extra symbolic links to get it all working.
ipkg install gcc-symlinks binutils-symlinks g++-symlinks cpp-symlinks ?
With this image I will be able to recompile some apps and compile new ones with iwmmxt optimisations.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141965\"][{POST_SNAPBACK}][/a][/div]
No you won't, *fpa is incompatible with iwmmxt.
-
I have found that simply installing gcc and related packages wont give you a working c compiler. I had to tweak several environment variables and create a few extra symbolic links to get it all working.
Could you let us know which ones please?
Thanks,
Si
-
I have found that simply installing gcc and related packages wont give you a working c compiler. I had to tweak several environment variables and create a few extra symbolic links to get it all working.
Could you let us know which ones please?
Thanks,
Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141976\"][{POST_SNAPBACK}][/a][/div]
ok, I didn't have cpp-symlinks so there's one less to be done, but from memory I had to symlink libgcc_s.so.1 from /lib to /usr/lib and I had to modify libc.so since ld complained about some parsing error. There was some additional stuff in libc.so that ld didn't like so I had to remove it. All the other symlinks I had to create were related to me moving all the files to /mnt/zgcc
koen: now I am confused about the *fpa being incompatible with iwmmxt. can you please clarify what you mean? I thought that Sharp/Cacko were using hard float which is fpa? and OpenZaurus uses soft float which is soft-vfp ? Also, the most significant iwmmxt optimised binary I know off is mplayer 1.1 by atty which was compiled for Sharp/Cacko but also works on pdaXrom.
-
the exceptions for fpa instructions are the same used for iwmmxt, so unless you are using eabi for everything you will run into problems
thats the only way i can express it, but basically they are mutually exsclusive under the current abi
anyway, i second the gcc issue, just installing the ipkgs dosent produce a working toolchain even if following the avalible infomation to the letter
-
I thought that Sharp/Cacko were using hard float which is fpa? and OpenZaurus uses soft float which is soft-vfp ?
No, fpa and vfp are two types of soft-float implementation, OZ uses fpa, pdaX uses vfp. See here: https://www.oesf.org/forums/index.php?showt...ndpost&p=124036 (https://www.oesf.org/forums/index.php?showtopic=18963&view=findpost&p=124036)
Si
-
anyway, i second the gcc issue, just installing the ipkgs dosent produce a working toolchain even if following the avalible infomation to the letter
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=142044\")
[a href=\"http://dominion.kabel.utwente.nl/koen/cms/building-ooo-natively]http://dominion.kabel.utwente.nl/koen/cms/...ng-ooo-natively[/url]
-
thanks for that, i will have a look at it latter. it seems to have more infomation than the other posts i have seen, if only i had seen it 2 months ago
-
I finally made a working zgcc image and as a test I compiled grisbi successfully
I will upload the cramfs image and the script I used to generate it when I get a chance...
files can be found here: http://zaurus.daemons.gr/menaie/openzaurus/ (http://zaurus.daemons.gr/menaie/openzaurus/)
-
Your script would be a lot simpler and foolproof if
* it would use package names instead of filenames
* it would use 'ipkg -o <dir> install <package name>' to install packages
Anyway, this script will be obsolete once o-hand.com merges their devgen-branch into OE.
-
* it would use package names instead of filenames
I thought it did use package names...
* it would use 'ipkg -o <dir> install <package name>' to install packages
I agree with this though, I think I'd prefer to install the apps (though the ideal method imho would probably be to create an ipk which depends on the other packages, and which does the symlinking/other fixes as a postinst. This may already exist in the form of the sdk*.ipk's)
Nevertheless, it is providing a native tool for those who are used to working with the zgcc images, so thanks for making the effort.
Si
-
* it would use package names instead of filenames
I thought it did use package names...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142354\"][{POST_SNAPBACK}][/a][/div]
'cpp_3.4.4-r5_armv5te.ipk' is a filename
'cpp' is a packagename
As soon as hrw adds a package update this script will break.
-
Ah, I see what you mean Koen.
That should be reasonably easy for Meanie to fix though.
Si
-
sigh
I rather make something that works first before worrying about extensibility and updatability. I was gonna enhance it later so it can be updated easily rather than over engineer it in the first go and never get something working together....
anyways, I just found that I can actually just run apps I compiled for pdaXrom on OZ/GPE
-
I rather make something that works first before worrying about extensibility and updatability. I was gonna enhance it later so it can be updated easily rather than over engineer it in the first go and never get something working together....
That's fair enough, koen was just pointing out how to make the script as low-maintenance as possible.
anyways, I just found that I can actually just run apps I compiled for pdaXrom on OZ/GPE
Interesting.... I thought that pdaX had an older version of libc or have they adopted the same version of libc with the 2.6.x kernel?
In that case, I do still wonder about the compatibility between the fpa and vfp floating point systems used by the two distros.
Si
-
a system with hard float can run soft float and hard float i belive while a soft float only cant run a hard float binary
apart from that i am not supprised that pdaxrom runs, they have enough in common IMHo the only thing that differs is how they compile packages and thier ideals or goals
-
Softfloat is managed by glibc+gcc, so you can mix and match *if* you compile stuff statically. Or use EABI, but that's a different story.