Hi!
Am 10.06.2010 17:27, schrieb Sergei Gorelkin:
What does FRAMETYPE = 1 mean?
Guess it is the value of FPC_EXCEPTION (trunk/rtl/inc/except.inc), the
only currently available/supported value for FrameType.
If I remember my analysis of FPC's exception system correctly, this
field is not
On 06/10/2010 10:30 PM, Den Jean wrote:
thanks to the fpc arm fix of Jonas, fpc is now working on the Nokia N900
(arm).
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/maemo_lcl_qt4.png
http://lists.lazarus.freepascal.org/pipermail/qt/2010-June/001547.html
Congrats !
Do I understand
En/na Michael Schnell ha escrit:
Is the N900 modified in any way to allow for loading and running native
Linux applications ? Do Linux command line tools easily run on the N900 ?
I don't have an n900, but previous maemo devices don't need any
modification to run native Linux applications
On 06/11/2010 10:28 AM, Luca Olivetti wrote:
Note that maemo is almost dead, due to the switch to meego (not that
it will change that much, since Qt will be natively supported instead
of being an add-on).
Sounds great !
Looking forward to the meego Widget Set selection in Lazarus :)
-Michael
Greetings,
The project I maintain includes several shared object libraries (.so
files, since we're dealing in Linux) which are built with FPC. We've
been using the 2.4.0 release of the compiler, but since I've heard the
release of 2.4.2 is upcoming, I decided to make sure everything builds
and
For what it's worth, this same problem occurs when using 2.5.1 from
the trunk (rev 15410) in svn.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
On Friday 11 June 2010 10:28:59 Luca Olivetti wrote:
Note that maemo is almost dead, due to the switch to meego (not that it
Do not exaggerate. N900 PR1.2 (Maemo 5 Qt 4.6.2) is only some weeks old,
MeeGo for arm is not even released yet, as its first target device
is not released either. The
Okay, here's an update with this problem: I started doing a binary
search through all the revisions of the fixes branch, and found that
revision 14365
(http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=14365)
introduced this problem.
If I check out rev 14364 I get the following when
On 11 Jun 2010, at 23:47, Seth Grover wrote:
But when I check out rev 14365 and recompile fpc then build my .so I get:
Reading symbols from /home/nitrodev/devel/bin/libESSDB.so...Dwarf
Error: Could not find abbrev number 10751 [in module
/home/nitrodev/devel/bin/libESSDB.so]
Can you put the
Okay, on further investigation, the specific revision from the trunk
which causes the problem 14336, which was merged into the fixes branch
as part of 14365. Building FPC from the trunk at rev 14335 does not
cause gdb to have the problem, but updating to 14336 does.
-SG
--
This email is fiction.
Jonas wrote:
Can you put the output of readelf -w /home/nitrodev/devel/bin/libESSDB.so
and of
readelf -wa /home/nitrodev/devel/bin/libESSDB.so online somewhere?
http://sites.google.com/site/sethdgrover/Home/dwarfdebug.zip
-SG
--
This email is fiction. Any resemblance to actual events
or
Jonas, after looking at that file you had me generate, I was able to
boil it down to a very simple case (http://pastebin.com/tX2f3ARe):
===
program Project1;
{$mode objfpc}{$H+}
CONST
(* query for finding found devices without connections
used in
Submitted to Mantis with the test case, thanks a lot.
http://bugs.freepascal.org/view.php?id=16705
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
13 matches
Mail list logo
