Qt 4.8.0 error

Screwface
Hi all,

I'm stuck with an error with Qt 4.8.0. I try to cross compile it and
integrate it in my rootfs. Here are the details :

- I'm working with emDebian Squeeze on a Mini2440.
- I use CodeSourcery compiler.
- I managed to cross compile tslib library, calibration works perfectly as
well as the test program

Now I want to cross compile Qt 4.8.0 library.

I modified mkspecs/qws/arm-linux-gnueabi-g++/qmake.conf as follow :

#
# qmake configuration for building with arm-none-linux-gnueabi-g++
#

include(../../common/linux.conf)
include(../../common/gcc-base-unix.conf)
include(../../common/g++-unix.conf)
include(../../common/qws.conf)

QMAKE_INCDIR += /usr/local/tslib/include
QMAKE_LIBDIR += /usr/local/tslib/lib

# modifications to g++.conf
QMAKE_CC                = arm-none-linux-gnueabi-gcc -msoft-float
-D__GCC_FLOAT_NOT_NEEDED -march=armv4t -mtune=arm920t
QMAKE_CXX               = arm-none-linux-gnueabi-g++ -msoft-float
-D__GCC_FLOAT_NOT_NEEDED -march=armv4t -mtune=arm920t
QMAKE_LINK              = arm-none-linux-gnueabi-g++ -msoft-float
-D__GCC_FLOAT_NOT_NEEDED -march=armv4t -mtune=arm920t
QMAKE_LINK_SHLIB        = arm-none-linux-gnueabi-g++ -msoft-float
-D__GCC_FLOAT_NOT_NEEDED -march=armv4t -mtune=arm920t

# modifications to linux.conf
QMAKE_AR                = arm-none-linux-gnueabi-ar cqs
QMAKE_OBJCOPY           = arm-none-linux-gnueabi-objcopy
QMAKE_STRIP             = arm-none-linux-gnueabi-strip

QMAKE_CFLAGS += -I/usr/local/tslib/include
QMAKE_LFLAGS += -L/usr/local/tslib/lib -Wl,-rpath-link=/usr/local/tslib/lib

QMAKE_CFLAGS_RELEASE += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4t
-mtune=arm920t
QMAKE_CXXFLAGS_RELEASE += -msoft-float -D__GCC_FLOAT_NOT_NEEDED
-march=armv4t -mtune=arm920t
QMAKE_CFLAGS_DEBUG += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4t
-mtune=arm920t
QMAKE_CXXFLAGS_DEBUG += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4t
-mtune=arm920t

I had to put the "-msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4t
-mtune=arm920t" in QMAKE_CC, QMAKE_CXX, QMAKE_LINK and QMAKE_LINK_SHLIB as
QMAKE_CFLAGS_RELEASE and QMAKE_CXX_FLAGS_RELEASE had no effect: the
binaries were built for armv5te.


I configured like this:

./configure -embedded arm -xplatform qws/linux-arm-gnueabi-g++ -prefix
/usr/local/Qt -little-endian -opensource -confirm-license -qt-mouse-tslib
-no-qt3support -nomake tools -no-cups -optimized-qmake

then make -j2 and make install -j2
I copied the libraries on my nfs rootfs
cp -r /usr/local/Qt/* /my-rootfs/usr/local/Qt/


Now, when I try to run an executable like demo for example, I get this
error message:

root@Mini2440:~# /usr/local/Qt/demos/embedded/fluidlauncher/fluidlauncher
-qws
/usr/local/Qt/demos/embedded/fluidlauncher/fluidlauncher: error while
loading shared libraries: /usr/local/Qt/lib/libQtCore.so.4: unexpected PLT
reloc type 0x0d
root@Mini2440:~# 


I don't understand what I'm missing. I tried to google a bit but found
nothing really interesting. And it takes ages to compile each time I try to
modify something, so if one of you could help me, it would be nice!

Thanks

Abolfazl Rostamzadeh
//in rc5 file
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/Qt/lib:$LD_LIBRARY_PATH

Screwface
Hello,

Thank you for your reply, but it doesn't change anything. I tried to
compile the library the same way using Pengutronix toolchain and then it
works.
But I would like to understand what's wrong with CodeSourcery toolchain as
I'm not used to use OSELAS toolchain, and juste for my personnal knowledge
also.

So if anybody has an idea...

Juergen Beisert
It seems you mix a binary distribution "emDebian Squeeze" with the binary
result of a cross toolchain from CodeSourcery on your PC based development
host. Not easy to maintain. Some info in the web about the error you face
points to "Most likely you linked it wrong, some object modules being from
the host machine." That's the job of a build system like PTXdist and OSELAS
toolchain: to avoid the host system can leak into your target's binaries.

davef
So, I understand correctly:

> I tried to
> compile the library the same way using Pengutronix toolchain and then it
> works.

Using a kernel generated by CodeSourcery?  Then, from my understanding you
were unfortunately lucky!

Screwface
I'm not sure to have completely understood:

Davef is right: I use a kernel + modules generated by CodeSourcery compiler
and an emDebian Squeeze root filesystem.

Juergen, I'm not sure to have completely understood your post. You mean I
should use the same compiler to cross-compile Qt as the one which was used
to create emDebian distro? In that case, I absolutely don't know which one.

davef
I am still confused.

So, you had a library built using Pengutronix toolchain, a kernel compiled
by CodeSourcery and a root file system  built by some unknown compiler and
it worked.  Pure luck.

For best and consistent results everything should be built using the same
compiler.  I guess people, who really know what they are doing have ways to
working out what is really important and work through all the resulting
errors.  But, I tell you my life got a lot easier sticking with one
compiler to do everything.

Juergen Beisert
Screwface, kernel and userland are two areas, they are (mostly) independent
from each other. Most of the time it is possible to run a newer kernel on
an older userland (but not the other way round). So, you can use a cross
compiler of your choice for the *kernel*. And also a different cross
compiler of your choice for *userland*.
But the different parts of your userland depend on each other (libraries
and applications). So, you must ensure they are using or are built with the
same libs and headers (and with the same revisions of these components).
Otherwise it crashes with a lot of funny error messages and you are hunting
phantoms.
An example (all revisions are guessed): Your emDebian was built with
GCC-4.5.1, and libc-2.7.19 and kernel 2.6.38 toolchain, your CodeSourcery
uses GCC-4.6.2, libc-2.14 and kernel 3.0. Then you cross compile your new
application with a 4.6.2 C compiler against a 2.14 libc/headers which
expects at least a 3.0 kernel for the API into the kernel. Then you copy
this program to your target and it will dynamically linked against a 2.7.19
libc and (may) run on a 2.6.39 kernel. So the compile time expectation does
not meet the run-time reality. Maybe it works, but most of the time it
crashes in a very confusing manner.

Screwface
Ok, so you mean you can not develop an application with a toolchain which
was not used to build the whole rootfs?
In that case, what's the use of a distro like emDebian? Only to use it with
already developed packages, or develop application with the same compiler?
How do you know all the GCC, libc and kernel versions used to generate
squeeze distro?

Juergen Beisert
> Ok, so you mean you can not develop an application with a toolchain
> which was not used to build the whole rootfs?

You can. Maybe it works, maybe not. In the "maybe not" case it is very hard
to find a solution.

You should ask the emDebian developers these questions. Maybe they have
already a solution for your use case.

Screwface
Ok, maybe I'd rather to use the correct versions used to create emDebian.
Anyway, I understand a bit more my problems, thank you very much for your
explanation.

Ravikumar
Hi,

Can I get a complete procedure to do the cross compilation of Qt4.8.0 for
mini2440 in ubuntu 12.04.


Thank you!

prahlad
Can I get a complete procedure to do the cross compilation of Qt4.8.0 for
mini2440 in ubuntu 12.04.

davef
Google for <mini2440vietnam> he has a good tutorial on a earlier version,
which should help you with the process.