16
Zaurus - pdaXrom / My Attempts To Build Qt4
« on: July 16, 2007, 05:00:05 pm »
Maybe, but glibc is very big library. On my PC it took more time to compile glibc then to compile qt... So it will be rather hard I think.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
-- Does anybody know if there is any plan to introduce an newer compiler in pdaxrom? (I've seen a bug report about this)Compilation of gcc-4.1.2 took me around 10h (natively). But it won't solve all problems.
-- Is it possible to build a newer glibc? mind that this point may need a rebuild of the repositories.
But more important, he pointed out that, even after succeeding he's found several errors that makes the library unusable (thanks man, you've saved me many hours of trial and error)This errors becouse of glibc. In fact there was a small warnings like that:
qlocale.o(.text+0x116e4): In function `qdtoa(double, int, int, int*, int*, char**, char**)':This is glibc warning (fixed in glibc 2.3.6), and that's why Qt have all those symbol errors, and etc (and that's why binary won't work). You can google it, if you don't belive. So main problem is very old glibc, not gcc.
: warning: warning: feholdexcept is not implemented and will always fail
Assuming cpu clock frequency 416MHz (ARMv6 disabled)
Please be patient and wait for the results, test requires quite a lot of time to run...
correctness tests passed
--- benchmarking with zero idct coefficients ---
simple_idct_armv5te time=751.9
simple_idct_put_armv5te cache=no, time=1988.0
simple_idct_put_armv5te cache=yes, time=860.2
simple_idct_add_armv5te cache=no, time=1136.2
simple_idct_add_armv5te cache=yes, time=923.1
simple_idct_armv5te_ref time=1131.8
simple_idct_put_armv5te_ref cache=no, time=1297.1
simple_idct_put_armv5te_ref cache=yes, time=1281.0
simple_idct_add_armv5te_ref cache=no, time=1625.5
simple_idct_add_armv5te_ref cache=yes, time=1385.5
--- benchmarking with random idct coefficients ---
simple_idct_armv5te time=1168.7
simple_idct_put_armv5te cache=no, time=2281.7
simple_idct_put_armv5te cache=yes, time=1277.0
simple_idct_add_armv5te cache=no, time=1595.2
simple_idct_add_armv5te cache=yes, time=1340.3
simple_idct_armv5te_ref time=1821.7
simple_idct_put_armv5te_ref cache=no, time=1988.0
simple_idct_put_armv5te_ref cache=yes, time=1981.6
simple_idct_add_armv5te_ref cache=no, time=2326.5
simple_idct_add_armv5te_ref cache=yes, time=2084.4
Where is this Gentoo for Zaurus? Is it easy to set up/boot? I may be interested...Generic stage for pxa27x based pda's It have wrong kb layout, you need to unpack it to cf/sd card and manualy fix fstab and /etc/conf.d/net (to use usb-net) then you can emerge other parts of system.
Thanks for the hints!No Problem. I was googling about Qt4 errors for a few days, after that I've realized that it is faster to kill pdaXrom and use Gentoo. Now it is compiling (30h already) without any warning...
After trying the cross compiling for a while I simply gave up, Qt is trying to build some tools to use them afterwards in its own build process... so I had to go native (at zaurus speeds)Yeah, Qt is very big library. It should took around 50h to compile it natively.
I knew the bit about the compiler, I had to disable the precompiled headers for having something going (it complained about some pch error after 3 hours of native compiling).In fact there is one thing that you haven't found - it says something like:
And yes, maybe the problems I am having are related to glibc (actually this brings light to the spot!) Does anyone know if there is an updated glibc version for pdaXrom?There was 2.3.2 for pdaXrom 1.1.0 Beta1 somewhere. But be careful - glibc 2.2.x and 2.3.x can be binary incompatible
On my side, I am still unable to compile Qt4, I'll keep tryingAs I remeber Qt4 needs at least glibc 2.3.2 (pdaXrom have 2.2.5 by default). Then it is recommended (but not necessary) to use gcc 4.x (can be easiliy compiled). Configure of qt4 by default can't understand that armv5te is arm and uses arch=generic. It may result in compiller error when it tries to compile x86 asm on arm... In theory Qt4 can be build (Angstrom have packages with Qt 4.3.0), but on pdaX it is very painful becouse of outdated libs.
well... It would probably be useful to merge angstrom patches to the pdaxrom kernel. EABI seems like a good idea. Further it would seem like a good idea to have a unified kernel. pas that, maybe a re-compile-fest to bring older apps with compatiblity problems up to speed?https://www.oesf.org/forums/index.php?showtopic=23865&st=75
not been able to figure out how to make a Angstrom kernel by starting from a vanilla one.http://www.openembedded.org/filebrowser/or...packages/linux/ - see linux-rp there.
I don't know where to find libiconv for x86 UbuntuMaybe it is called just iconv?
(and can it be done on a 6000, or just the newer clamshells?)Any machine that have kernel 2.6 and u-boot working.
I thought altboot used kexec?Yes, it use kexec, but it also starts rather fast... So maybe it can be useful for dual booting?
Although I do not like it much currently the solution that would take the least effort for multi boot is kexec with a rare exception of r121+ pdaxrom versions that can share the same kernel (as a matter of fact on my C860 I have r198 in nand and a higly modified r121 in MMC and use just u-boot to select whic one to boot).And what about OZ's altboot? I thought it could boot system from other than nand devices...
Would it be possible to do the same and boot from the microdrive instead ? (I'm looking for a solution to run r198 from microdrive) ?In theory. I was trying to get Gentoo boot from microdrive, but for some reasons kernel detects partitions after booting (see at emergenc system - I got there "Unknown partiton layout" - same thing I get if when booting from microdrive)