Qt segmentation fault

Hello,
I want to develop software for the mini6410 with qt.

So I installed qt embedded (4.7.0) and Qtcreator on my ubuntu.

I can compile and run C programs like:

#include <stdio.h>

main()
{
  printf("Hello World\n");
}


But a (empty) qt-programm doesn't work (hallo.cpp):
#include <QtCore/QCoreApplication>


int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
    return a.exec();
}

make works and file says:
hallo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.14, not stripped

I copied it to the mini and chmod +x it and then a ./hallo gives me the
Segmentation fault:-(

What's wrong with my QT?

Greetings from Germany
Holger

Try ./hallo -qws

> Try ./hallo -qws

I did. The same error:-(

Need I qtopia on the Desktop?
Need I a specific version of QTCreator? But I compile it at the console
with make not with the Creator.

Run your app with "strace" to get an idea what libraries it tries to load.
Then compare the library revisions on your target with the cross compiled
ones at your development host (from the libc of your toolchain). If they
are not the same, this can be the cause of your segmentation fault.

There is no strace on the mini:-(

Do you know http://www.friendlyarm.net/forum/topic/3015 ? Maybe you should
start with it to get the root filesystem and its content under your
control.

Looks interesting, but no USB support? Than it is useless for me. I need a
3G Modem, GPS mouse, rfid reader. All are usb devices.

At the moment I need a working qt. I recompiled it with the Friendlyarm
toolchain. But the result is the seg. fault on the mini:-(

Ok, I tested more. C and C++ programms are running but no QT! I tried the
hello examplefrom the dvd. Also a segmentation fault. I think something
with the qt libs on the mini is incompatible. 
I will try to compile these new and report.

Also you want to check all your cross-compiled files with:

readelf -A <filename>

especially your Qt libs as you mentioned.

Ah, ok... for the example in the first posting only libQtCore.so.4.7.0 is
needed.
On my pc:
$ cd /usr/local/Trolltech/QtEmbedded-4.7.0-arm/lib 
$ readelf -A libQtCore.so.4.7.0
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM1176JZF-S"
  Tag_CPU_arch: v6K
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_optimization_goals: Aggressive Speed


The same lib from the mini:
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM1176JZF-S"
  Tag_CPU_arch: v6K
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_optimization_goals: Aggressive Speed

The "Tag_FP_arch" is on the pc VFPv3 and on the mini VFPv2. Is that the
problem? If yes, how can I solve this?
And what is with the "Tag_Advanced_SIMD_arch" that is not present in the
lib from the mini?

To make it work in a reliable way, everything on your target must be made
with the same toolchain (compiler, libc, assembler and so on). If not, you
will search for phantom bugs until the end of your life.

hmm... so I have to recompile qtopia and qte for the mini with the same
FriendlyARM toolchain I compiled it on the Desktop? Thats not a very
userfriendly way:-( There is an qt on the mini, so I should be able to use
it. It should be work like in Debian for example, I need not to recompile
all programs to work on it.
Very strange...!

What you need is, the runtime libraries must be the same (or at least built
in the same way) way as the development libraries. Think about if your
program is linked against revision X of a library and on the target
revision Y of this library is available. How should that work in a reliable
way?
What you need is a development environment that matches the state of the
libraries available on your target (this means for example all header files
define things that matches the runtime libraries). And a toolchain which
builds everything new against this environment. Then your results will work
on the target. Maybe this kind of development environment is part of the
CD/DVD (I didn't check yet)?.

I solved the problem! It was not a problem with any libs.
The problem was the ftp program (filezilla).

The following worked on the mini:
arm-linux-gcc hello-world.c

Transfered the a.out to the mini, chmod +x and worked.

arm-linux-gcc -o hello-world hello-world.c

does not work. The binary was exact the same.

The transfermode in filezilla was set the automatic. After I set it the
binary the hello-world works.

But now I had problem with an gui example. Only a butten and a inputfield
created with QtCreator. Tested it with:
./guitest -qws
Transformed: Driver not found
Aborted

I recompile my qt-lib on the host with -qt-gfx-transformed and will try
again.
Thanks for your help.

How should re-compiling the Qt lib on your host help? You need the
differently configured and built Qt lib on your target.

Yes. I copied the new libs also to the target and get an illegal
instruction. 
The pre-installed examples are working (with the original libs), so I think
something with my program is wrong for the mini. 
The new compiled libs don't work on the Mini but I can compile without
errors or warnings with them. 
I compiled them on a amd64 Gentoo machine with the Friendlyarm toolschain.
The toolschain should work correct, because the C and C++ programs I
compiled with it are working. 

So I think the failure is in the tslib or in the qte. 
Ok, first I will check if a qt console application is working.

Or whats a working configure for the qte?

So, the hello example in the arm-qtopia 2.2.0 from the dvd is working.

I can open and modify the hello_base.ui with the QtDesigner from the dvd.
It is version 1.1!!! Also installed is QtDesigner 4.7.4, but it seems the
resulting ui-files ar not compatible. The new designer couldnot open the
ui-file and with an new ui-file (from the 4.7.4 designer) the make fails.

In the old designer for example changes in font size dont matter:-(

Is it able to use the new designer? 

How can I change font and font size? I make an app for working with finger
and the small default font is much to small:-)

GREAT Thanks Holger! I fought two days with same Filezilla problem.
Segmentation fault.
But now I got this readelf -A procedure to get it just right so it was all
for good. It really does not need to be even close to correct for program
to run: 
My out of box compilation (arm-linux-gnueabi-gcc  hello.c -o hello) on
Debian gives like:
 Tag_CPU_name: "ARM9TDMI"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int

It runs OK on linux modem!
Here is same out of box compilation from Ubuntu:

Tag_CPU_name: "5T"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int


It runs OK.
But the most basic library on the modem itself(libc.so.6) gives totally
different elf:
Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_DIV_use: Not allowed