OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: ernestus on July 16, 2007, 07:33:27 am
-
Hi
My original idea was porting some old Qtopia apps to Qt4, and building other google-found Qt utilities. The memory resources used by Qt4 and its speed compared to old versions impressed me. Porting the old Qtopia apps would make the Z a kinda Super X PDA Mini Laptop... yes, I know, sometimes I am like a teenager
Well, I needed Qt4 but it wasn't in the repositories, so...
I've been trying to build the latest Qt4 for pdaXrom for the last two or three weeks. Something that I thought that was going to be a simple cross compiling turned out to be very tricky.
The first problem was Qt itself, it builds a series of tools that are used later in the build process itself , that makes cross compiling really hairy (I would have to tweak their build process, so no way...)
So I went to on Zaurus compiling... The Z is very slow (I have a SL-C3200 and it's speed is that of a 200 Mhz Pentium) And the build takes ages. I launch the build, and I get an error several hours later (Civil says the whole process should take about 50 hours).
A byproduct of this attempt is I've assembled together several parts and "constructed" (not written) a kind of SL-C3200 toy emulator based on qemu that goes well ONLY if you want to do native builds (thanks guys, I took most of my tools from you). The only not so good news are it is not much quicker than the Z running in my laptop (an Intel core duo @ 2Ghz ). BTW the emulated RAM can be as much as 256M, so this speeds the build a little bit, and I don't wear my Z microdrive.
The errors I had in this native build are:
-- Related to the precompiled headers. I think is related to the old version of GCC I am using (gcc 3.4.6). I disabled them when invoking the configure script., and solved that problem.
-- Some errors related to include files and symbol definitions. I've been tweaking one by one, you have to think I launch the build and I have the errors back many hours later, so it goes very slowly. I thought it was related to the qmake spec file I was using to build Qt, but Civil remarked that the glic version included in pdaXrom it's very old (glibc 2.2.5). 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)
And now my questions:
-- Does anybody know if there is any plan to introduce an newer compiler in pdaxrom? (I've seen a bug report about this)
-- Is it possible to build a newer glibc? mind that this point may need a rebuild of the repositories.
Before I finish a remark:
In my crappy-good-for-nothing-but-at-least-it-compiles emulator I am mixing some pdaxrom and some openzaurus, and they work very well together. Won't make sense to make pdaxrom a kinda usability-oriented angstrom flavour? those guys have a really slick distro (technically speaking), but not as friendly as pdaxrom.
Of course, thanks again.
E
-
-- Does anybody know if there is any plan to introduce an newer compiler in pdaxrom? (I've seen a bug report about this)
-- Is it possible to build a newer glibc? mind that this point may need a rebuild of the repositories.
Compilation of gcc-4.1.2 took me around 10h (natively). But it won't solve all problems.
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**)':
: warning: warning: feholdexcept is not implemented and will always fail
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.
-
You can google it, if you don't belive. So main problem is very old glibc, not gcc.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164994\"][{POST_SNAPBACK}][/a][/div]
Of course I believe you
Well, then the thing to do is recompiling glibc, it shouldn't be any problem to have both glibc in my system (I hope so).
-
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.
-
I would love qt4 for the zaurus ...
last time I paid $100 to get it (Qt3?) compiled for pdaxrom.
I'll do it again for Qt4.
Scott
-
I would love qt4 for the zaurus ...
last time I paid $100 to get it (Qt3?) compiled for pdaxrom.
I'll do it again for Qt4.
Scott
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165071\"][{POST_SNAPBACK}][/a][/div]
any chance we can impose on lpotter to help us wth this (for pdaxrom)?
-
Hi all.
As Civil remarked before, there is an issue with glibc, the one included in pdaxrom is quite old. Yesterday I downloaded the latest stable glibc and I expect to compile it in the weekend. I will trigger another Qt build and I hope there are no more issues.
I think some key components in pdaxrom need a revamp, the present ones are a little aged and interfere with the porting of the latest cool app I-cannot-live-without, the best I can do is offering those components packed and ready to install. If I have time (I am going on hols in two weeks) I will assemble together an updated toolchain, with the latest stable GCC and glibc.
There is no problem in linux having multiple versions of a dll (a shared object in linux jargon, or a so file), but glibc is bulky and this may leave out the people with models without a microdrive.
Hmm, I suspect Civil may have done all of this before, ...
-
when I tried building qtopia 1.x when I was doing cacko stuff, what I had to do was build it natively on x86 completely, then start in a new directory and kick off the cross compilation build.
when it then barfed trying to run things like moc and other trolltech tools, I copied over the x86 binaries into position (moving the arm ones out of the way) and fiddled with the file dates so that when I restarted the build it didn't kill the x86 binaries.
it worked fine, and I ended up with x6 binaries of the design tool and so on... I was able to then build and test my programs entirely in x86 space (using qvfb to emulate the handheld's display - that's the virtual frame buffer application), and then build them for zaurus and copy the binary to zaurus and run it there.
-
Hmm, I suspect Civil may have done all of this before, ...
I haven't tried to build glibc - it is too big for native compile. And my 2-nd PC is too weak to have pdaX86 on vmware/qemu for cross-compilation
There is no problem in linux having multiple versions of a dll (a shared object in linux jargon, or a so file), but glibc is bulky and this may leave out the people with models without a microdrive.
Linux distro can have multiple copies of glibc and you can compile software against one of them. At least something like that was done in OpenOffice 1.x thread (on oesf of course). The main problem is gcc is a very large lib to be native-compiled (I think it'll took 4-5 days to compile it on Z)
-
I would love qt4 for the zaurus ...
last time I paid $100 to get it (Qt3?) compiled for pdaxrom.
I'll do it again for Qt4.
Scott
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=165071\")
There [a href=\"https://www.oesf.org/forums/index.php?showtopic=16885&hl=qt4]already is[/url] qt4 for pdaxrom.
-
but too old version of QT4
How Angstrom do it ? they have 4.3.0 version ...
-
How Angstrom do it ? they have 4.3.0 version ...
They have rather up-to-date environment (glibc 2.5, gcc 4.1.2, etc.)
-
The question that comes to mind, though, is whether the existing qt4 is sufficient to begin work on WebKit and maybe qlwm?
-
I would love qt4 for the zaurus ...
last time I paid $100 to get it (Qt3?) compiled for pdaxrom.
I'll do it again for Qt4.
Scott
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=165071\")
There [a href=\"https://www.oesf.org/forums/index.php?showtopic=16885&hl=qt4]already is[/url] qt4 for pdaxrom.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165104\"][{POST_SNAPBACK}][/a][/div]
*laugh* and I even mirrored it. :-> WE just need one with the new canvas -- etc --> 4.3.x +
Scott
-
Interesting enough we already have one... I will have a look at it later, but, anyway, I think a new set of libs and tools may easy the port of new apps...
Will see what I do.
-
[yeah..updating the libs (and hopefully passing them back into pdaxii13) might be agood idea.
-
It looks like the kernel guys would like to have a newer compiler as well, so I am here, well after midnight building a toolchain
-
I'm waiting anxiously -- I haven't upgraded my my zauruses in about 2 years now.
Having Qt4 available would be the trigger for me to upgrade.
Scott
-
By the way, I've managed to compile qt-4.3.0 on my zaurus's gentoo (glibc 2.5, gcc-4.1.2, eabi).
-
By the way, I've managed to compile qt-4.3.0 on my zaurus's gentoo (glibc 2.5, gcc-4.1.2, eabi).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165260\"][{POST_SNAPBACK}][/a][/div]
And ... ? We all know it compiles everywhere else , except pdaxrom
-
By the way, I've managed to compile qt-4.3.0 on my zaurus's gentoo (glibc 2.5, gcc-4.1.2, eabi).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165260\"][{POST_SNAPBACK}][/a][/div]
And ... ? We all know it compiles everywhere else , except pdaxrom
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165272\"][{POST_SNAPBACK}][/a][/div]
Not for too long, I hope
-
Some problems compiling glibc
=========================
Well, I managed to compile:
1 - The last binutils,
2 - The last GCC (4.2.1, released just 4 days ago, without glibc support)
so the two other steps needed to have the complete toolchain are:
3- Compiling glibc (this is the problematic point read more)
4- Compiling GCC 4.2.1 again with glibc support (to be honest, once point 2 has succeeded, I don't expect problems here)
The amazing case of the problematic point 3
----------------------------------------------------------------
Well, when the build of glibc failed I thought it was related to GCC 4.2.1, many times, the latest compiler is not able to compile glibc, so I tried to build it with the 3.4.6 tool chain available somewhere in the forum, with the same result.
I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6, does anyone know what happened to it, I cannot find it anywhere? I am tempted to use the one for glibc 2.5 instead (will try this evening), but I am reluctant to do so, because of the possible stability issues (may trigger very difficult to find bugs, thread related issues are very hairy matters)
I may go back to glibc 2.5 (but, this is not the COOLEST, LATEST and GREATEST release)
Choosing the target
----------------------------
Another question, I've built the compiler with options for softfloat and xscale, there is another very interesting one iwmmx:
- does anyone know what is the difference of compiling for a iwmmx target insead of a xscale one? both are exclusive, OR you compile for a xcale target OR you compile for a iwmmx target, not both. My guess is that choosing the iwmmx target may produce code able to run in iwmmx enabled PXA's but not in others, but I may be wrong.
- how can it render the compiler incompatible with older pxa devices?
Any hint is appreciated.
thanks all
E
-
I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6
Linuxthreads was removed. Use NPTL instead of it.
Another question, I've built the compiler with options for softfloat and xscale, there is another very interesting one iwmmx:
- does anyone know what is the difference of compiling for a iwmmx target insead of a xscale one? both are exclusive, OR you compile for a xcale target OR you compile for a iwmmx target, not both. My guess is that choosing the iwmmx target may produce code able to run in iwmmx enabled PXA's but not in others, but I may be wrong.
- how can it render the compiler incompatible with older pxa devices?
armv5te compiler can generate code with march=iwmmxt, march=xscale and march=armv5te.
-
I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6
Linuxthreads was removed. Use NPTL instead of it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165283\"][{POST_SNAPBACK}][/a][/div]
Yes, I do, but the compilation then fails because of undeclared symbols that I think are related to linuxthreads. Maybe I need a header or something like that.
I will post the precise error tonight.
-
qt4.4 is out!
http://www.linuxdevices.com/news/NS8928092497.html (http://www.linuxdevices.com/news/NS8928092497.html)