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 th
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 understa
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 (ma
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 :)
-Mich
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 wor
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=rev&revision=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
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
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 ND_
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
