Help - Search - Members - Calendar
Full Version: My Attempts To Build Qt4
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom
ernestus
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 rolleyes.gif

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
Civil
QUOTE
-- 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.

QUOTE
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:
QUOTE
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.
ernestus
QUOTE(Civil @ Jul 16 2007, 08:45 PM)
You can google it, if you don't belive. So main problem is very old glibc, not gcc.
*


Of course I believe you wink.gif

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).
Civil
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.
ScottYelich
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
adf
QUOTE(ScottYelich @ Jul 17 2007, 09:25 PM)
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
*

any chance we can impose on lpotter to help us wth this (for pdaxrom)?
ernestus
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, ...
speculatrix
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.
Civil
QUOTE
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

QUOTE
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)
ShiroiKuma
QUOTE(ScottYelich @ Jul 17 2007, 10:25 PM)
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
*

There already is qt4 for pdaxrom.
kkazakov13
but too old version of QT4 sad.gif


How Angstrom do it ? they have 4.3.0 version ...
Civil
QUOTE
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.)
adf
The question that comes to mind, though, is whether the existing qt4 is sufficient to begin work on WebKit and maybe qlwm?
ScottYelich
QUOTE(ShiroiKuma @ Jul 18 2007, 08:09 AM)
QUOTE(ScottYelich @ Jul 17 2007, 10:25 PM)
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
*

There already is qt4 for pdaxrom.
*



*laugh* and I even mirrored it. :-> WE just need one with the new canvas -- etc --> 4.3.x +

Scott
ernestus
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.
adf
[yeah..updating the libs (and hopefully passing them back into pdaxii13) might be agood idea.
ernestus
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 smile.gif
ScottYelich
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
Civil
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).
kkazakov13
QUOTE(Civil @ Jul 23 2007, 03:01 AM)
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).
*


And ... ? We all know it compiles everywhere else , except pdaxrom smile.gif
ernestus
QUOTE(kkazakov13 @ Jul 23 2007, 07:31 AM)
QUOTE(Civil @ Jul 23 2007, 03:01 AM)
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).
*


And ... ? We all know it compiles everywhere else , except pdaxrom smile.gif
*



Not for too long, I hope wink.gif
ernestus
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
Civil
QUOTE
I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6

Linuxthreads was removed. Use NPTL instead of it.

QUOTE
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.
ernestus
QUOTE(Civil @ Jul 23 2007, 03:34 PM)
QUOTE
I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6

Linuxthreads was removed. Use NPTL instead of it.
*



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.
speculatrix
qt4.4 is out!
http://www.linuxdevices.com/news/NS8928092497.html
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.