Active Topics
-
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 13 hrs, 17 mins ago -
Nokia Booklet 3G (RX-75) Drivers (60)
to Alternatives by Maemish - 5 days, 21 hrs ago - more...
dragly |
2010-05-12
, 14:36
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#11
|
Originally Posted by jamie721
Thanks for the info. I'm testing on device, yes. Haven't actually tested it in scratchbox for a while since scratchbox has full OpenGL, and I wanted to check that everything was fine using OpenGL ES.
|
|
2010-05-12
, 16:35
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#12
|
While getting home from work, I started thinking about linking issues. You can get really special behaviour if you link against one library and move the binary to another environment to run it.
Are you sure that you're using the same library to run the binary as you use to link it? I got random segfault just a week ago from linking against a newer version and then running the application in the target environment that had an older version installed.
Are you sure that you're using the same library to run the binary as you use to link it? I got random segfault just a week ago from linking against a newer version and then running the application in the target environment that had an older version installed.
|
|
2010-05-12
, 16:58
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#13
|
Originally Posted by Joorin
Well, the scratchbox SDK is PR1.2, and my device is (of course) still PR1.1. I know libhildon has changed in PR1.2, but the Qt libraries should be the same (libqt4-maemo5).
While getting home from work, I started thinking about linking issues. You can get really special behaviour if you link against one library and move the binary to another environment to run it.
Are you sure that you're using the same library to run the binary as you use to link it? I got random segfault just a week ago from linking against a newer version and then running the application in the target environment that had an older version installed.
Do you think libhildon could be causing this?
 |
|
2010-05-12
, 17:01
|
|
Posts: 754 |
Thanked: 630 times |
Joined on Sep 2009
@ London
|
#14
|
qt libraries are not exactly the same on the device and PR1.2 SDK.
the PR1.2 SDK has QT 4.6 by default.
the PR1.2 SDK has QT 4.6 by default.
__________________
Developer of :
Buddy - budget/expense manager ( website )
Showtime - a telly channel listing viewer/reminder ( website )
Travelapp - london underground status/planner ( website )
Batlevel - desktop widget for battery level ( website )
“I hear and I forget. I see and I remember. I do and I understand.”
Developer of :
Buddy - budget/expense manager ( website )
Showtime - a telly channel listing viewer/reminder ( website )
Travelapp - london underground status/planner ( website )
Batlevel - desktop widget for battery level ( website )
“I hear and I forget. I see and I remember. I do and I understand.”
|
|
2010-05-12
, 17:11
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#15
|
Originally Posted by krk969
The libqt4 package in the PR1.2 SDK is Qt 4.6.2, and in PR1.1 it is Qt 4.5, but I'm using the libqt4-maemo5 package, which I believe is the same (Qt 4.6.2) on both PR1.1 and PR1.2. I might be wrong though.
qt libraries are not exactly the same on the device and PR1.2 SDK.
the PR1.2 SDK has QT 4.6 by default.
|
|
2010-05-12
, 17:13
|
|
Posts: 1,038 |
Thanked: 737 times |
Joined on Nov 2005
@ Helsinki
|
#16
|
Try running your code in fullscreen mode. If you are running opengl application with the titlebar, then you are running multiple opengl contexts, which makes the compositor and application do SGX context switches all the time, completely destroying speed.
|
|
2010-05-12
, 17:19
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#17
|
Originally Posted by konttori
We've already done that, but thanks for the tip
Try running your code in fullscreen mode. If you are running opengl application with the titlebar, then you are running multiple opengl contexts, which makes the compositor and application do SGX context switches all the time, completely destroying speed.
|
|
2010-05-12
, 19:47
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#18
|
Originally Posted by dragly
Check and double check. If it's the same libraries, they should be the same size.
The libqt4 package in the PR1.2 SDK is Qt 4.6.2, and in PR1.1 it is Qt 4.5, but I'm using the libqt4-maemo5 package, which I believe is the same (Qt 4.6.2) on both PR1.1 and PR1.2. I might be wrong though.
| The Following User Says Thank You to Joorin For This Useful Post: | ||
|
|
2010-05-12
, 21:04
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#19
|
Originally Posted by Joorin
I just checked the sizes, and on device /opt/libqt4-maemo5 is 42652 bytes, while in scratchbox is 42988.
Check and double check. If it's the same libraries, they should be the same size.
Can't this difference be because of the underlying file system? Both package versions (on device and in scratchbox) are 4.6.2~git20100212-0maemo1.
Thanks for all your suggestions so far!
The next step will be to comment out different parts of the code to isolate the error, like Joorin suggested 
|
|
2010-05-13
, 12:01
|
|
Posts: 12 |
Thanked: 13 times |
Joined on Feb 2010
|
#20
|
Originally Posted by dragly
While the underlying filesystem may store the libraries differently, and may take up different amounts of actual space, when exposed to user level programs, there will be no difference at all if they are the same file. If they are different, and really are the same library, then one of them is corrupted, it's that simple. Or, if they are different and not corrupted, then they are not the same library. Since Scratchbox has the ARM binaries, we can rule out the difference being because of x86/ARM architectural differences.
I just checked the sizes, and on device /opt/libqt4-maemo5 is 42652 bytes, while in scratchbox is 42988.
Can't this difference be because of the underlying file system? Both package versions (on device and in scratchbox) are 4.6.2~git20100212-0maemo1.
Thanks for all your suggestions so far!
You could compare the output of md5sum on both libraries to be absolutely certain since it reads each file in it's entirety to produce the checksum, but since they are different sizes, I can guarantee you'll get different checksums - meaning they are not the same file.
| The Following User Says Thank You to rivierakid For This Useful Post: | ||