Re: [fpc-devel] Re: Building the Android branch

[Den]

Hi Sven/Thomas,

  I was just wondering if you guys could give me a hand as well. I'm 
currently interested in using the Native "targetandroid" branch.  Right 
now I'm getting the error:


fpcmake -p -Tarm-android Makefile.fpc
Processing Makefile.fpc
Error: No targets set

This is the section of my build script:

ANDROID_LIB_DIR="$HOME/android-ndk-r8b/platforms/android-9/arch-arm/usr/lib"

export 
CROSSBINDIR="$HOME/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/arm-linux-androideabi/bin"

export CROSSOPT="-CfSOFT -CpARMV5 -Fl$ANDROID_LIB_DIR"
export OS_TARGET="android"
export CPU_TARGET="arm"

make clean crossinstall

Is there a reason it's not using the fpcmake that has been created with 
crossinstall?


Any help would be greatly appreciated!
Thank you for your time!

- Dennis Fehr


On 12-12-19 10:18 AM, Sven Barth wrote:

Am 19.12.2012 16:42, schrieb Thomas Schatzl:

On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote:

Am 18.12.2012 17:47, schrieb Thomas Schatzl:

Looking through compiler/systems/t_android.pas, you may want to try
commmenting line 343, the one that adds info.Dynamiclinker to the
input files. Looks wrong. (system/bin/linker is passed to ld later as
--dynamic-linker option later anyway).

Ok... by removing the addition of the dynamic linker I can successfully
compile and link the DLL, but when starting it I get an illegal
instruction error... I have not yet tested whether this can be
reproduced with an empty library as well.

=== logcat begin ===

[...]

=== logcat end ===

Edit: Linking with debug information I could resolve the address to
InterlockedExchange. Hmm... It seems that the SDK's QEMU does not
emulate a ARMv6 device?

- yes. See http://developer.android.com/tools/devices/emulator.html.
Btw, there is not much point to compiling for armv6 for Android. The two
official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16
(maybe v2).

Then I'll need to recompile for ARMv5...

- if you are really interested about doing Android development, I
recommend getting a developer board. The emulator is really slow. Even
fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7
with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This
device is actually pretty decent. Otherwise use an unused phone.
Currently I'm mostly checking what would be necessary to get our 
Windows Mobile application (more or less) running on Android using 
LCL-CustomDrawn. For these tests the emulator and maybe my own Phone 
should be enough for now.


Thanks again. I'll report back if the situation improves :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Building the Android branch

[Den]

Hello again Sven/Thomas,

Sorry about the post again, you can ignore the previous post. I got 
targetandroid compiling with my buildscript.
I just had to do a make -C "$HOME/fpc-droid/utils/fpcm" before the 
actual make process, and setting PATH to 
"$HOME/fpc-droid/utils/fpcm:$PATH" as a workaround.


I'm sure when it is merged you won't have to worry about the 
fpcmake as it will be aware of arm-android.  I thank you very very much 
for starting this branch.  I just wish I would've stumbled upon it 
sooner rather than doing it myself based on arm-linux.  A quick demo 
works now with Android's NativeActivity.  I imported Google's 
'libandroid_native_app_glue.a' and the headers from the 
lcl/interfaces/customdrawn/android interface from Lazarus with success.  
I only had to change the 'ANativeActivity_onCreate' translation.  Now if 
only you could include NativeAppGlue (record's and procedure interfaces) 
and the other header translations from 
lcl/interfaces/customdrawn/android that would be most excellent. :)


Thank you very much again for saving me a lot of time.

- Dennis

On 12-12-19 10:18 AM, Sven Barth wrote:

Am 19.12.2012 16:42, schrieb Thomas Schatzl:

On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote:

Am 18.12.2012 17:47, schrieb Thomas Schatzl:

Looking through compiler/systems/t_android.pas, you may want to try
commmenting line 343, the one that adds info.Dynamiclinker to the
input files. Looks wrong. (system/bin/linker is passed to ld later as
--dynamic-linker option later anyway).

Ok... by removing the addition of the dynamic linker I can successfully
compile and link the DLL, but when starting it I get an illegal
instruction error... I have not yet tested whether this can be
reproduced with an empty library as well.

=== logcat begin ===

[...]

=== logcat end ===

Edit: Linking with debug information I could resolve the address to
InterlockedExchange. Hmm... It seems that the SDK's QEMU does not
emulate a ARMv6 device?

- yes. See http://developer.android.com/tools/devices/emulator.html.
Btw, there is not much point to compiling for armv6 for Android. The two
official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16
(maybe v2).

Then I'll need to recompile for ARMv5...

- if you are really interested about doing Android development, I
recommend getting a developer board. The emulator is really slow. Even
fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7
with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This
device is actually pretty decent. Otherwise use an unused phone.
Currently I'm mostly checking what would be necessary to get our 
Windows Mobile application (more or less) running on Android using 
LCL-CustomDrawn. For these tests the emulator and maybe my own Phone 
should be enough for now.


Thanks again. I'll report back if the situation improves :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] INCLUDESTRINGFILE patch.

[Den]

Hi all,

I must say, it is actually quite fun to be a part of the FPC 
Developers mailing list, I don't know why I didn't join sooner. Quite 
interesting conversations and ideas, a little bit of bickering but very 
understanding people in general, I like it.  I want to add my two cents 
before continuing to the point of this email:


  - I do like the FPC Community development style.  This means that if 
I want a feature I can add it myself, which I've done.  All it takes is 
a proposal, some others come in with similar experience with Pascal and 
recommend a few fair changes which all makes sense.


  - Florian is correct.  It's quite easy to make a compiler.  If you 
need it, just build it.  I've made a Virtual Compiler of a programming 
language I invented in the past, which had it's own Virtual Runtime 
(executed with Assembly of course) for FUN.  It really isn't that hard.  
The one difference is, with Free Pascal, you get to be a part of a group 
which is fun.


Now down to the actual point of the email:

  -- May I get my patch here ( 
http://bugs.freepascal.org/view.php?id=21848) approved and in trunk? 
I've been using it in 2.6.x and 2.7.x for awhile now and it works quite 
nicely.  I did the INCLUDESTRINGFILE as requested. ^_^


Anyway, I must say I love the targetandroid branch so far.  I've 
got my Project working using Google's libandroid_native_app_glue.a, and 
my Game Engine works nicely on Linux/Android (with setup for Windows and 
iPhone coming soon).  Keep up the great work everyone. Can't wait to see 
targetandroid merged with trunk!



- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Adding a Package to the SVN packages list for a specific Platform

[Den]

Hi all,

I'm a bit unfamiliar with the packages build system, and was 
wondering how to add 'openal' for example, to the win64 list for SVN FPC 
building? I would like the openal package to be compiled when I compile 
for win64.  I would have thought by adding it to Makefile.fpc.fpcmake, 
it would have added the package to that Target, but it does not.


Thanks in advance.

- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Adding a Package to the SVN Packages list for a specific Platform

[Den]

Hi all,

I'm a bit unfamiliar with the packages build system, and was 
wondering how to add 'openal' for example, to the win64 list for SVN FPC 
building? I would like the openal package to be compiled when I compile 
for win64.  I would have thought by adding it to Makefile.fpc.fpcmake, 
it would have added the package to that Target, but it does not.


Thanks in advance.

- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Adding a Package to the SVN Packages list for a specific Platform

[Den]

Hi all,

Nevermind, looked in the sources, and learnt more about the FPMake 
system.  I kinda like it, beats Makefiles for sure.  Just thought there 
was an automatic way to build the fpmake.pp in each directory based on 
other 'spec' files, but it appears not, so I just edited the fpmake.pp 
files in the respective package directory, pretty simple stuff..


Disregard this question after all!

- Dennis Fehr

On 13-07-02 01:51 PM, Den wrote:

Hi all,

I'm a bit unfamiliar with the packages build system, and was 
wondering how to add 'openal' for example, to the win64 list for SVN 
FPC building? I would like the openal package to be compiled when I 
compile for win64.  I would have thought by adding it to 
Makefile.fpc.fpcmake, it would have added the package to that Target, 
but it does not.


Thanks in advance.

- Dennis Fehr


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] DOS GUI

[Den]

Hey Thaddy,

Sorry to do a quick run-by hijacking of a thread, but I updated the 
EGL/GLES20 patch (on bug tracker) to remove X dependency in Linux.  
Thought I might share it with you as to not have you do extra work you 
don't have to and include it all in one patch.


Apologies to all!

- Dennis

On 14-01-16 10:25 AM, Thaddy wrote:
My whole point is: add a license that you find suitable to your 
intend. But add a license. Pref compatible with the fpc licenses.


In the case of the company: I almost forgot about it. You can be 
right, but not in the us of a without big pockets to enforce it. (In 
Europe it is much easier, in the Netherlands you just deposit your 
code with at the tax office - a lttle uknown -)




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] CPPClass

[Den]

Hi all (but most likely Sven ;) ),

I've noticed the CPPClass no longer works and stops with: 
internalerror(200611034) -- From [compiler/ncgrtti.pas]


It's a case when generating the Object Definition RTTI ASM-Data, 
and doesn't handle odt_cppclass.. (Hence the internal error).  Any way 
you could update the CPPClass to a working condition? I'd really like to 
use it as I would rather write a Pascal CPPClass and interface with a 
Library rather than making my own bridge library and interfacing with that.


Let me know!


Sincerely,

Dennis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CPPClass

[Den]

I would definitely be interested in it.  I am done a project in 
about 3 months, so it would be *cough* (AWESOME) if you could by then 
*cough*! ;)


- Dennis

On 14-01-18 08:12 AM, Sven Barth wrote:

On 18.01.2014 06:19, Den wrote:

Hi all (but most likely Sven ;) ),

 I've noticed the CPPClass no longer works and stops with:
internalerror(200611034) -- From [compiler/ncgrtti.pas]

 It's a case when generating the Object Definition RTTI ASM-Data,
and doesn't handle odt_cppclass.. (Hence the internal error). Any way
you could update the CPPClass to a working condition? I'd really like to
use it as I would rather write a Pascal CPPClass and interface with a
Library rather than making my own bridge library and interfacing with 
that.


Currently it only works with static or at least non-virtual methods 
anyway. Also instantiation or destruction of C++ classes will not work 
yet alone exceptions. So I don't know whether such a fix would help 
you much.


Maybe once my Master Thesis is done I'll find more time to work on 
this again.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CPPClass

[Den]

haha, well Sven, if some of my patches were to get accepted *cough* 
I'd help out a lot more.
I am just kinda tired of seeing such a huge difference in local 
modifications and the actual source.  I would be more inclined to help 
you on some of these in about 3-4 months if I could see them actually 
getting accepted lol


- Dennis

On 14-01-22 03:55 AM, Sven Barth wrote:

Am 22.01.2014 10:48, schrieb Marco van de Voort:

In our previous episode, Sven Barth said:

 - Windows RT ?

 The list just does not end... :/


You forgotten about "Invoke" function in RTTI.pas ;)

Right you are ^^
See what I meant with the never ending list? :P

Fixing the implements keyword (#8951)? Anonymous methods?

  ( : -) )

*sigh* See? :P

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CPPClass

[Den]

Yep!

$INCLUDESTRINGFILE -- http://bugs.freepascal.org/view.php?id=25536
Apache24 Patch -- http://bugs.freepascal.org/view.php?id=25534
EGL/OpenGLES20 Split -- http://bugs.freepascal.org/view.php?id=25535

Although I have an updated version of the Apache24 which supports 
Config Options better and a few more macros.


I also have a small fix for 'WinSock2' inclusion which makes it actually 
get included in the Win32/Win64 FPMake (looks like it was planned but 
never added).


- Dennis

On 14-01-22 12:35 PM, Florian Klämpfl wrote:

Am 22.01.2014 19:31, schrieb Den:

 haha, well Sven, if some of my patches were to get accepted *cough*

What patches? Are they available somewhere?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CPPClass

[Den]

I noticed you got the WinSock2 one when it conflicted with a file, 
I just chose to use the SVN copy as it was pretty much the same.


I'd like to update my Apach24 patch but it seems I can't seem to 
log-in to the Free Pascal bugs area.. It says my account is either 
blocked, disabled, or I entered the username/password incorrectly.  I've 
been logging in the same way for many many years lol .. can someone 
check the error out for me? That would be most excellent. :)


And I saw your comment on the $INCLUDESTRINGFILE! Yes, of course! I 
would love to include a test case and such.  Thank you for looking at it 
Sven.  I was also thinking about the maximum size issue.. Should we use 
a constant for the Size Restraint? Or a parameter? (Or even another 
directive?)


- Dennis

On 14-01-23 02:31 AM, Sven Barth wrote:

Am 23.01.2014 00:26, schrieb Den:

Yep!

$INCLUDESTRINGFILE -- http://bugs.freepascal.org/view.php?id=25536

I commented there just now.

Apache24 Patch -- http://bugs.freepascal.org/view.php?id=25534

Already assigned to Michael.

EGL/OpenGLES20 Split -- http://bugs.freepascal.org/view.php?id=25535
If noone beats me to it I'll take a look after my Master's thesis is 
done.


Although I have an updated version of the Apache24 which supports 
Config Options better and a few more macros.

There is still time to update your patch :P
I also have a small fix for 'WinSock2' inclusion which makes it 
actually get included in the Win32/Win64 FPMake (looks like it was 
planned but never added).

I already fixed that yesterday.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] CPPClass

[Den]

I've managed to log back in again, and all is well! I implemented 
the new INCLUDESTRINGFILE directive, and test case and etc.. The full 
message is in the bug report. ^_^


- Dennis Fehr

On 14-01-23 03:28 PM, Sven Barth wrote:

On 23.01.2014 19:30, Den wrote:

 I'd like to update my Apach24 patch but it seems I can't seem to
log-in to the Free Pascal bugs area.. It says my account is either
blocked, disabled, or I entered the username/password incorrectly.  I've
been logging in the same way for many many years lol .. can someone
check the error out for me? That would be most excellent. :)


Could be related that we switched off the community site.

@Florian, @Jonas: Does anyone of you know what Dennis could do?


 And I saw your comment on the $INCLUDESTRINGFILE! Yes, of course! I
would love to include a test case and such.  Thank you for looking at it
Sven.  I was also thinking about the maximum size issue.. Should we use
a constant for the Size Restraint? Or a parameter? (Or even another
directive?)


I haven't thought that much yet.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizations

[Den]

Excellent work Florian! Makes me want to work on those parts of the 
compiler.. Though my current interests are in other parts of it.

But very nice. :)

On 14-01-25 04:55 PM, Florian Klämpfl wrote:

Am 25.01.2014 23:00, schrieb Sven Barth:

On 25.01.2014 17:09, Florian Klaempfl wrote:

Am 24.01.2014 09:32, schrieb Sven Barth:

Am 24.01.2014 02:03, schrieb Martin Frb:

There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for what the author wanted.
http://bugs.freepascal.org/view.php?id=10275

In that context... @Florian: how is your SSA support coming along? :)

Still WIP :) But a lot of my commits from the last weeks are spin-offs
of the SSA work.

Together with all other improvements this results in significant better
code:

fpc -l -O3 sha256.pp -S2
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling sha256.pp
Linking sha256.exe
74 lines compiled, 0.1 sec , 26016 bytes code, 2220 bytes data

fptime sha256
Expected: 3994057095, got 3994057095
483.000 ms


pp -n @c:\fpc\bin\fpc.cfg -l -O4 sha256.pp -S2
Free Pascal Compiler version 2.7.1 [2014/01/25] for i386
Copyright (c) 1993-2013 by Florian Klaempfl and others

fptime sha256
Expected: 3994057095, got 3994057095
367.000 ms

Nice :D
Still looking forward to more improvements regarding SSA ^^

Most could be probably gained in this example by moving variables into
xmm registers if only certain kind of operations are carried out on them.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Atn: Florian (Revision 26636)

[Den]

Hi Florian!

You had done a bit of work with OP_SHR/OP_SHL it seems with the 
revision (in cgx86.pas/nx64mat.pas), but now I can't seem to 
cross-compile to Win32 from my Linux64 OS.. (It fails with Internal 
Error 200109223 in popt386.pas, as it is most likely the first SHL 
operation?) Am I the only one experiencing this?


Thanks!

- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] function overload ?

[Den]

If you're not worried about the slight speed hit and extra space on the 
stack for the return value of "My" you could always have it as a Variant?


  function My(const a : Integer) : Variant;

Then assign it to whatever variable?

- Dennis Fehr


On 14-02-03 12:54 AM, Gennadiy Poryev wrote:

Hi!

I had a dream :)
Wouldn't it be nice if a function overload took care not only of 
formal parameter list (per docs) but also of result type? So the 
following may work

function My(const a : Integer) : AnsiString; overload;
function My(const a : Integer) : WideString; overload;
by substitution of the function depending on the expected type of the 
expression it is being called from?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] One fpc.cfg per fpc version

[Den]

Why not fpc-$FPCVERSION.cfg? And keep them all in /etc/ ? fpc-2.6.2.cfg, 
and fpc-2.7.1.cfg, etc.
This way fpc will use it's version and search for the right one in a 
standard directory?


- Dennis Fehr

On 14-02-16 12:14 PM, Mattias Gaertner wrote:

On Sun, 16 Feb 2014 15:28:59 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:


[...]
I played with this in 1.9.2 times iirc.

IIRC the principle was developed for cases where every version installed
into a prefix with make INSTALL INSTALL_PREFIX=~/somethingversion.  (so that
you also had multiple bin directories and everything was fully separated).

Yes, for example make install INSTALL_PREFIX=~/2.6.2 installs to
~/2.6.2/lib/fpc/2.6.2
Which looks odd.

Maybe fpc should search for /fpc.cfg.

Then maybe the current search for /../etc/fpc.cfg can be
removed. Only a few people use it and they will probably be happy to
have more flexibility where to install fpc.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Type/Record Helper SVN Change (Atn: FPC-Core Members)

[Den]

Hi all to FPC Core,

I was wondering why the change to have a modeswitch for the 
Type/Record Helper? In Delphi there is no such switch needed.  Doing 
something like:




program TestHelper;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
  TStringHelper = record helper for String
function Length: Integer;
  end;

var
  S: string;
begin
  S := 'Test String';
  Writeln(S, ', length: ', S.Length);
  ReadLn;
end.



Should work out of the box (this example was taken straight from a 
Developer of XE3 btw).


- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Can no longer convert Set of Enum to Integer (on latest SVN ... as of 5-10 minutes ago)

[Den]

Hello all,

As the subject implies, code that has previously ran:

---

Type TSomeEnumSet = Set OF (seOne, seTwo, seThree, seFour);

Var SomeSet : TSomeEnumSet;

Begin
  Writeln(Integer(SomeSet) );
End.

---

Results in: Error: Illegal type conversion: "TSomeEnumSet" to "LongInt"

---

This should be possible (in the documentation for a set " The compiler 
stores small sets (less than 32 elements) in a Longint"), what has 
changed? (using latest SVN as of 5-10 minutes ago :p)



- Dennis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Cannot Forward Declare a Generic Class

[Den]

Hi there,

Is there a reason why I cannot forward declare a Generic Class?

TSomeClass = Class;

TSomeOtherClass = Class
  Obj : TSomeClass;
End;

TSomeClass = Class
End;

--

  Yes, I know I could put TSomeClass inside TSomeOtherClass, but 
there are 2 other classes that back reference each other and it's quite 
the pain without being able to forward declare the Class.  Can this be 
implemented? I'm tired, so I may not be thinking of the implications of 
why.. I suppose I'll have to use some good ol' fashioned {$INCLUDE}'s 
inside the other class.


- Dennis Fehr

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Binary Package System Discussion?

[Den]

Hello all,

I know this has been brought up from time to time, but the more I 
use NetBeans and other big editors.. The more I miss the fact that it 
isolates you from being in their pool of source code to build whenever 
you add a component, etc.  Having a binary-only Lazarus would mean an 
entire overhaul of a binary package system.  What would be amazing to 
see actually, is FPC being able to compile into a universal object 
(which supports the basic byte code, and sections which will only be 
used when converting to a certain architecture if necessary.. Like SSE 
optimized code), then being able to convert into native code at 
destination machine.  Something like Chrome's Native Client does now, 
which compiles the code into a universal op-code base, and converts it 
to native at their servers..


Having this universal binary package system, means we can 
distribute one package, and have it convert on the destination machine.  
Means we don't really have to do tricks when distributing your unit when 
you don't want to distribute the source code (ie. Commercial Packages).


Any thoughts?

- Den
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Binary Package System Discussion?

[Den]

Hi Sven!

I suppose you can just have Build Servers and build all major 
OS/Architectures.  The platform differences could be solved by an 
additional 'target dependent' package.  But I suppose with the Dynamic 
Packages, we could just bundle the different architectures in the one 
Package File, and have a header which states which architectures it has 
in it, or even in the file listings in the Package in a certain 
directory.  When that time comes, fun stuff will happen, as the Lazarus 
could be made to auto-update and such for the normal folk. (I know mine 
is practically auto-update.. Update VCS and then rebuild :p ) and then 
there's FPCUP .. But just thought something like Netbeans.


I was also thinking, when I have time, I wanted to make an API for 
Lazarus which devs could make their own VCS and have it display in the 
IDE, to make it more modern.. But I have a project due very very soon, 
so I can't really work on it yet. :p


Anyway, thanks for the reply Sven! I'll have that bug fix tested as soon 
as I get a moment.

Take care!

- Den

On 14-09-06 03:29 PM, Sven Barth wrote:


> Any thoughts?

Dream on. FPC is a native compiler and someone would need to implement 
that proposed bytecode and maintain it.
Even once we support LLVM we wouldn't drop any of our native code 
generators and even if we did LLVM simply does not support all those 
platforms that we support (e.g. m68k as CPU or OS/2 as OS).
Additionally there'd still be the platform differences which would 
stop you from distributing one set of blobs: on Windows you need to 
use the WinAPI, on Linux C API and X11 and on Mac OS X C API and 
Carbon/Cocoa. If you'd encode all this currently handled by ifdefs and 
different units into those blobs you could simply distribute the 
source as well.


Please note that support for binary packages (aka dynamic packages) 
will come. But they will depend on a target just as compiled units 
currently do already.


Regards,
Sven



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI generating

[Den]

Well, what frustrates me is that there are always people that come up 
with all kinds of fancy ideas/add-ons/additions that bring absolutely 
nothing in "real" improvement


Ahem, it seems when people DO bring patches and improvements to the 
table, they never get accepted, and discourage any more improvements 
from them in the future.. *Cough* .. *Cough* ... :p


*Refers to INCLUDESTRINGFILE and OpenGL ES/EGL Split I made* .. At least 
my Apache Patches got applied. :p (Thanks Michael!)


I really want to become FPC/Lazarus a really stable, reliable 
development, across multiple platforms, without constantly trying to 
run along the other "kool kids on the block"...


Like I said before, I would be willing to contribute more if my patches 
were to get included and not just laying there now.  I even implemented 
every suggestion and created tests (for the INCLUDESTRINGFILE one anyway).


- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI generating

[Den]

Hi Sven,

What would you say the status on Generic Methods/Functions if you 
were to give a status for it?


- Dennis Fehr

P.S. I see you added CPPClass support to the bottom of that list, very 
much looking forward to that too! .. I know it's kinda a bit difficult 
as you have to follow the VMT of C++ as it is incompatible with FPC's -- 
Obviously lol


On 14-09-19 05:19 PM, Sven Barth wrote:


Am 19.09.2014 23:39 schrieb "Boian Mitov" >:
> I even offered to donate our enhanced RTTI API to the FPC community 
with very little interest so far :-( .


Your API would be welcome, but it's of no use when we don't yet 
generate the data your API relies on. And implementing that takes a 
sufficient amount of free time. Don't forget that we work on FPC on 
our free time without being paid for it (mostly at least). And then 
the extended RTTI isn't the only thing that wants to be implemented. 
Just a short list of those:


- dynamic packages (working on that)
- generic methods and functions (working on that)
- attributes (being worked at) and extended RTTI
- invoke (needs generic methods for TValue)
- anonymous functions (being worked at or not... Don't know the 
current state)

- Vector Pascal support
- the new array initializers from XE7
- interface delegation to classes
- usable cppclass support

Regards,
Sven



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Android "Text Relocations"

[Den]

Hiya!

I'm working on an Cross Platform Project, and when compiling to 
Android-ARM and getting it onto the Android Device, in ADB Logcat it 
shows library has "Text Relocations", and that I should get rid of them 
and it's a security risk.. AFAIK I don't have any units that are 
compiled with PIC.. May I ask how to remove these text Relocations, and 
possibly a bit more information about them and why they're being 
included without PIC?


Thank you!

- Dennis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Android "Text Relocations"

[Den]

Hi Jonas,


I guess you mean "without PIC"?


Yep, I did mean without PIC, my apologies (we're trying to get RID of 
relocations! I had written the email in a hurry).


At first sight, the RTL startup code contains non-PIC assembly 
(rtl/android/arm/prt0.as and rtl/android/arm/dllprt0.as)


Thanks for the heads up, should've thought to look there. :p

- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Generics, TObject Descendant?

[Den]

Hi there,

Currently this code:

  TSomeObject = Class;
  TSomeOtherObject = Class(TSomeObject );

And finally:

  TMyObject = Class;
  TSomeOtherOtherObject = Class(TSomeOtherObject );

Comes up with error 'got "T" expected "TObject"' .. But TMyObject is 
based off of TObject?


- Dennis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics, TObject Descendant?

[Den]

Ahh, thanks Sven! I'll see if I can post a bug report soon of it.. I'll 
use the work-around for now. :)


On 2015-02-19 12:22 AM, Sven Barth wrote:

On 18.02.2015 20:51, Den wrote:

Hi there,

Currently this code:

   TSomeObject = Class;
   TSomeOtherObject = Class(TSomeObject );

And finally:

   TMyObject = Class;
   TSomeOtherOtherObject = Class(TSomeOtherObject );

Comes up with error 'got "T" expected "TObject"' .. But TMyObject is
based off of TObject?


At seems that there are still problems if TMyObject is merely a 
forward declaration... the following works:


=== code begin ===

type
  TSomeObject = Class
  end;

  TSomeOtherObject = Class(TSomeObject );

  TMyObject = Class
  end;

  TSomeOtherOtherObject = Class(TSomeOtherObject );

=== code end ===

Note 1: this is a forward declaration "XYZ = class;", this is not: 
"XYZ = class(TObject);"
Note2 : a generic /must not/ be a forward declaration (in this case 
TSomeObject).


A forward declaration of TMyObject should be valid in this case 
however, so please report a bug with an example program attached.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] ref count issue with out param

[Den]

It is similar to type tarray = array [1..10] of longint; procedure 
p(const a1 : tarray;var a2 : tarray); begin a2[1]:=4321; 
writeln(a1[1]); // surprise end; var arr : tarray; begin arr[1]:=1234; 
p(arr,arr); end. The only way to prevent this (of course, such a 
simple case could be detected by the compiler but one can always 
construct an example which works around this detection), is to turn 
off the const optimization that const allows the compiler to pass only 
a reference, but I am pretty sure, people will not be happy about this :)

Correct. Would definitely not be happy about this. :)

- Dennis

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Enable LLVM?

[Den]

Hi there!

I was just wondering if there was an option to enable compiling to 
LLVM bitcode? I see a bit of work happening in SVN from it, and would 
love to start using it.


- Dennis Fehr
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Enable LLVM?

[Den]

Ah, thanks for giving me a heads up Jonas.  I'll have to wait and see 
where it goes then.  Do you have a page/blog where I can keep up to date 
with your progress/roadmap of it? :)


- Den

On 2015-07-13 05:15 AM, Jonas Maebe wrote:

Den wrote:

 I was just wondering if there was an option to enable compiling to
LLVM bitcode? I see a bit of work happening in SVN from it, and would
love to start using it.


You cannot use it, because it does not work yet. And as mentioned in 
earlier messages:
* it will need architecture and OS-specific support per target (I'm 
only working on Darwin/x86-64 right now)
* it will probably only work with specific LLVM versions, because LLVM 
only cares to an extremely limited extent about backward/forward 
compatibility
* LLVM's handling of parameter passing is split between Clang and LLVM 
in a way that makes it impossible for third parties to support it in a 
reliable way (although some people are looking into splitting off that 
functionality into a - C++ - library; not sure how useful that would 
be for FPC)


LLVM also makes a lot of assumptions that are wrong as far as non-C 
languages are concerned. For example, the result of a load from a nil 
address is considered to be "undefined", which means they (and every 
instruction that depends on such a result) may be "optimised" away 
completely by LLVM. In Pascal (or at least FPC), you instead expect a 
segmentation fault if that happens. You can find a few other such 
issues documented at 
http://www.mono-project.com/docs/advanced/runtime/docs/llvm-backend/ , 
but there are more. They are open to fixing such assumptions (or to at 
least add a command line parameter to disable them), but I'm not aware 
of anyone actually working on LLVM to do this (and I'm not going to do 
that myself either).


Finally, it is not possible at this time to combine units compiled 
with a regular code generator with units compiled with LLVM due to 
differences in the PPU format between the two. I don't know if it will 
be possible to solve this without a significant rewrite of in 
particular our handling of inline functions.


Just to say: don't get your hopes up that it will just be a simple 
"recompile and take advantage of all LLVM features", especially in the 
beginning.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Pascal Standard, and what we can do.

[Den]

Hi all,

There's been recent talk about adding a new dialect and such, and I 
just wanna weigh in that I don't think it's a very good call to split 
Free Pascal even more.. I believe Free Pascal had such potential.. And 
the reason I mention 'had' is the fact that makes Free Pascal 'strong' 
also makes it it's biggest weakness and downfall; The fact that there is 
no direction and lead, and everyone can add whatever they want.  The 
difference between Free Pascal and successful big languages are 
*leadership*, *roadmap*, *community*, *support*.  Now I know the usuals 
will start immediately thinking 'yes but it's all volunteer, we don't 
have the man power' .. Why is many other languages believed to be more 
popular?


*Standards**.*

If we had a group of people that designed standards (/a group 
document??/), people like me can see the new standard and say 'oh, nice 
I like that feature, I'm gonna implement it'. Let's say someone else 
makes a completely LLVM compiler based on that standard? So what if it's 
not one program, at least Pascal would 'survive'.  Just like ECMAScript, 
C++, PHP, most languages now have a 'standards' document behind it.  
That's their *roadmap*. Their *leadership*.  Design it and the 
*community* will show *support*.  I know I would actually feel like 
working towards it, because then I know when they are approved I'm not 
wasting my time creating features and such, just to have them rejected 
and never implemented. ;)


I would personally love to add to such standards, and we can add some of 
the collective wisdom of ours. :) (/I have 22+ years of experience with 
Pascal, and I'm sure Florian, Sven, Marco, and Jonas all have similar if 
not much more; and would be excellent at adding to the standard/)


- Dennis Fehr

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Pascal Standard, and what we can do.

[Den]

I am quite aware of ISO Pascal.. Though, to be fair it wasn't well 
known and the tools for adding 'rfc' style proposals must not have been 
great? I've proposed a few new properties to the CSS documents standard, 
and you know what? It felt great. They're discussing it now and I can 
track it.  If it succeeds, it will be implemented.  It's things like 
that, having a group effort with the documents and the actual 'technical 
engineers' work on it.  You won't have to worry about big heads and 
businesses taking over the document, as it will be an open effort, just 
like FPC is.  When someone looks at a roadmap, that's the 'output' 
people look to and see on what to expect in the future.  What we'd be 
doing is discussing proposals and such to make Free Pascal a standard.  
Who knows? Maybe Delphi would start trying to implement our standards?


Is there any such online software anyone is aware of, that is an 
easy 'proposal'/'rfc' style interface? Where you can make suggestions, 
comments and votes on each proposal? If there is enough votes on a 
particular proposal someone could see the potential and add it without 
fear of it not being accepted.


- Dennis Fehr

On 2015-07-19 04:42 PM, Ralf Quint wrote:

On 7/19/2015 2:03 AM, Jonas Maebe wrote:

Den wrote:

Just like ECMAScript,
C++, PHP, most languages now have a 'standards' document behind it.
That's their *roadmap*. Their *leadership*. Design it and the
*community* will show *support*.


ISO Pascal and ISO Extended Pascal were like that in the early 90s:
1) there was an official ISO standard and standards committee for it
2) there were a number commercial compilers supporting it such as HP 
Pascal and IBM's compiler for its System/370
3) later on (in 1996) a GCC-based implementation arrived for it (the 
equivalent of the LLVM of the moment)


And still almost no one uses ISO/Extended Pascal anymore. Why? 
Possibly because the de facto Pascal standards had already become 
Think Pascal on the Mac and Turbo Pascal on the PC by then, and none 
of those programmers wanted to rewrite all of their code (although 
Think Pascal was a bit closer to ISO Pascal). Or maybe because in 
general, many people just preferred those language dialects for one 
reason or another. In any case, introducing one new standard to rule 
them all seldom (if ever) works (and you can bet someone will be 
unable to resist to add a link to the related xkcd comic).


Standards do not magically make a language more popular. They only 
work if they follow from a desire of an entire community to design 
one and to adhere to it. "Design it and the community will show 
support" is exactly the opposite of what happens in practice.
ISO Pascal was a born a dead horse. Borland, itself taking pieces of 
USCD Pascal (Units, Strings) became the "de-facto"standard and that is 
what the initial goal was when Florian started the compiler way back 
when. Later, Free Pascal followed what was set by Delphi, making the 
most sense.
Now today, I do not necessarily agree with the direction Embarcadero 
heading these days with Delphi and most importantly (for me), I do not 
agree with all those attempts to add "features" of other languages to 
Free Pascal. I appreciate the efforts of the folks involved in Free 
Pascal for a long time, as this provides me with the opportunity to 
keep working in the programming language/environment that for me makes 
the most sense and that I am used to for 38 years. And I honestly 
loath to see that people argue that there should be new language 
constructs and such, just because it is what more popular programming 
languages provide. I am not in to participate in a popularity contest, 
I am trying to get work done...


Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Pascal Standard, and what we can do.

[Den]

Looks like I sparked quite a bit of interest! Perhaps we could work 
on a Standard instead of just on the Compiler itself? This gives people 
more of a look on what 'could' happen, instead of a Wiki where everyone 
can just edit.  A system where voting is necessary, just like Standards 
from W3C, Khronos, etc, etc. A mailing list where people debate 
endlessly is not productive; we could have had a # of votes to see what 
should/should not be implemented, instead of a few key members deeming 
what's 'pascalish' or not. You may create that fork/branch now, but who 
knows who will actually end up merging it in? If they ever do. This is 
why we need a standard, so that there is NO wasted work, and people can 
get experience implementing things that are well documented first and 
know how they should act.


*Plan first, Then Code*: I believe was said? ;)

Then let us plan a standard, and what each feature should do, *then code*.
I hope there is enough rally for this to happen!

- Dennis Fehr

On 2015-07-24 02:29 AM, Maciej Izak wrote:
2015-07-23 11:22 GMT+02:00 Michael Van Canneyt >:



The most convenient technological argument is compatibility
with Oxygene.


Well, that's a political argument, I think: we can choose to be
not compatible with Oxygene :)
(whether or not this would constitute suicide or not, is up for
debate)


To start any work on this I need to provide a few more patches related 
to Delphi compatibility. I would like to return to the subject in near 
future.


The rest is in many cases a matter of taste. We can endlessly
debate what
is more readable :)


Good. Now you're talking sense :)

I look forward to your contributions!


Nice to hear that. So I guess I don't need any fork ;) phew!

--
Best regards,
Maciej Izak


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Pascal Standard, and what we can do.

[Den]

Actually, I recently proposed several changes to CSS, and I'm not a part 
of their working group.  I can even track the status of it.


- Dennis Fehr

On 2015-07-24 06:02 AM, Marco van de Voort wrote:

In our previous episode, Den said:

  Looks like I sparked quite a bit of interest! Perhaps we could work
on a Standard instead of just on the Compiler itself? This gives people
more of a look on what 'could' happen, instead of a Wiki where everyone
can just edit.  A system where voting is necessary, just like Standards
from W3C, Khronos, etc, etc.

Neither is voting by uninformed people. People admitted to W3C and Kronos
are a preselected group, not every internet user can vote directly on
proposals.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Pascal Standard, and what we can do.

[Den]

Yes, and why does an email/submission not in itself count as a 
vote? This isn't a 'threat' to the Free Pascal eco system, I'm trying to 
help! I hope the 'usuals' aren't thinking that I'm trying to stand up, 
go against, or similar? A standard can only help Free Pascal. It is up 
to us to have no bigger company take over the Standard. An Open 
Standard. I just want to raise Pascal to a level I think it deserves, 
and think this would be a great way for people to come together and 
voice their opinions/votes on specific features. I'm not asking for 
things like inline variables, etc. But I am asking that we stay up to 
date with coding functionality, and expect a certain result. It's the 
worst when someone comes up with an idea, adds it in FPC, and turns out 
people have issues against how it works, or the result wasn't as 
expected, etc.


- Dennis

On 2015-07-24 07:04 AM, Michael Van Canneyt wrote:



On Fri, 24 Jul 2015, Den wrote:

Actually, I recently proposed several changes to CSS, and I'm not a 
part of their working group.  I can even track the status of it.


Sure. Everyone can submit, why not ?
Marco said "vote" :)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Enable LLVM?

[Den]

Good results! Thanks for keeping us updated, keep it up! :)

- Dennis Fehr

On 2015-07-30 11:58 AM, Jonas Maebe wrote:

On 14/07/15 10:13, Jonas Maebe wrote:

No, just the svn commit log. The status right now is that the system
unit for Darwin/x86-64 can be mostly compiled and "assembled" (i.e., the
generated LLVM IR can be successfully parsed by llc -- although since it
doesn't get completely to the end, I may not have seen all errors for
code coming before that yet) other than
a) RTTI

This has now been implemented as well. With some local hacks and a few
manual changes to the generated code, the system unit for Darwin/x86-64
can now be compiled and successfully assembled. Note that this is with
all inline assembly code removed (and pure inline assembly functions
just returning 0 or its equivalent, so a lot of code is wrongly
optimised away by llvm based on that).

Some results are interesting, like the lowercase(shortstring) function
becoming a rather impressive vectorised jungle:
http://pastebin.com/vpugp80e . The only other vectorised functions in
the system unit are lowercase(shortstring),
UCS4StringToUnicodeString/Widestring, ArrayStringToPPChar and the
helpers to add/sub/mul/symdif large sets.

On the other hand, it seems that loading an array as a plain value in
llvm bitcode results in rather suboptimal code (this is with -O2):
http://pastebin.com/krXhuEzF :)


Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] tagSIZE is missing in FPC 3.1.1

[Den]

haha, I didn't think twice about jumping to where the function result 
was defined, seeing it was TSize, then renaming it and recompiling it 
within seconds.. Pretty sure the SVN will match up with my edit lol


- Dennis Fehr

On 2015-11-18 04:23 AM, Mattias Gaertner wrote:

On Wed, 18 Nov 2015 13:29:19 +0330
MohsenTi  wrote:


I try to compile lazarus with fpc 3.1.1 and get tagSIZE missing error.
tagSIZE type using by canvas and in older fpcs are in types unit.

I removed the last tagSize in Lazarus 10h ago.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI

[Den]

On 2015-11-25 04:38 AM, Michael Van Canneyt wrote:


One must admire the subtle announcement in this reply ;-)


I know, right?? :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Stack alignment on i386

[Den Jean]

Hi,

to interface with c libraries containing SSE code, 
the stack must be aligned to 16 bytes.

Currently the default -mpreferred-stack-boundary=num of gcc provides for this.

However current fpc 2.4.4 does not align the stack as such.
I do not know if this correct or not when reading things like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c8
http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1

I tried to change alignment with {$CODEALIGN 16} but this didn't work.

kind regards,

Den Jean




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Den Jean]

On Sunday 18 December 2011 14:05:00 Jonas Maebe wrote:
> That's because it changes the alignment of procedures (code), rather than
> that of the stack. You cannot change this setting via a switch, it's
> hardcoded in the compiler as part of the ABI.
The problem is that gcc already changed this long ago,
and to interface with library binaries of a distribution (compiled by gcc),
fpc does not provide an option. For the Qt binding I hope I solved it, 
so I am not in need of anything.
> Changing this will also require quite a few changes in the RTL as well to
> be safe (e.g., in case cmem is used and if the glibc memory manager one
> day would use sse), because the RTL contains lots of assembler code that
> doesn't care at all about stack alignment. The places where there's an
> {$ifndef darwin} in i386-specific files can probably help, since
> Darwin/i386 also requires a 16-byte aligned stack. The assembler startup
> code for Linux/i386 probably also needs to be adapted.
> Overall, it's not a trivial c> hange to make properly.
Thanks for the information.

regards,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Den Jean]

On Monday 19 December 2011 08:04:30 zeljko wrote:
> How ? 
The binding now aligns the stack before calling the Qt libraries



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Den Jean]

On Tuesday 20 December 2011 10:36:12 Sven Barth wrote:
> Ok, that doesn't help me then, because I'm directly using OpenCV which I 
> didn't (and don't want to) compile myself.
that is why I wrote that to interface with library binaries of a distribution 
(compiled by gcc),fpc does not provide an option.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Den Jean]

On Sunday 18 December 2011 14:05:00 Jonas Maebe wrote:
> since Darwin/i386 also requires a 16-byte aligned stack

Does this mean I can drop these stack alignment options for Osx 32 and 64 bit?
Anyhow my old OsX has gcc 4.0.1 and does not have all these options.
It has mstackrealign but not the -mincoming-stack-boundary=num

regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Den Jean]

On Tuesday 20 December 2011 23:51:28 Jonas Maebe wrote:
> Yes. Any program that does not have a 16 byte alliged stack on Mac OS
> X/i386 will crash almost immediately, because the dynamic linker enforces
> it. You also don't need it on any x86-64 platform, because they all have
> always required a 16 byte aligned stack.
thx for the information, I will remove these options on Darwin and x86-64.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] enums and integer auto conversion

[Den Jean]

Hi,

As described in 
http://bugs.freepascal.org/view.php?id=22797

fpc 2.7.1 does not allow anymore to pass an enum
to a function expecting integers.

Note that there has always been a
{$MINENUMSIZE 4} in qt4.pas

Is this intended behaviour ? I really hope it is not.

I cannot define the type of the parameter
as the enumtype because the expected values
are either the enum or combinations of the enum (or)

Kind regards,

Den Jean

 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] enums and integer auto conversion

[Den Jean]

On Monday 10 September 2012 20:18:52 Vincent Snijders wrote:
> If it is the combination of enum, then the type of the parameter is set of
> enum.
Ahum, I am talking about passing combinations of enums values
(usually bitmasks, assigned enums, some assigned enums
are already combinations of other) to C or C++. 
Sets are not binary compatible for that.





 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Arm Hardfloat

[Den Jean]

Hello,

I am trying to compile for hardfloat.

When passing floats as parameters to a C-library function call,
I get incorrect values inside the library.
Both for singles as doubles.

If I write the same call to the c-library in c, 
I get assembler like

call function test_param (int, single, single)

  test_param (i,f1,f2);  

ldr r0, [fp, #-8]
fldss0, [fp, #-12]
fldss1, [fp, #-16]
bl  test_param

  test_param (142,1.1,2.2);

mov r0, #142
fldss0, .L3
fldss1, .L3+4
bl  test_param

In pascal I get the following assembler for this call

  test_param(i,f1,f2);

ldr r0,.Lj10
ldr r2,[r0]
ldr r0,.Lj6
ldr r1,[r0]
ldr r0,.Lj13
ldr r0,[r0]
blx test_param

  test_param(142,1.1,2.2);

ldr r2,.Lj5
ldr r1,.Lj8
mov r0,#142
blx test_param
blx FPC_DO_EXIT
ldmea   r11,{r11,r13,r15}
.Lj5:
.byte   205,204,12,64
.Lj8:
.byte   205,204,140,63



Pascal compiler options like
fpc -Aas -O- -CfVFPv3 -Cparmv7 -CaEABI  pmain.pp
or
fpc -Aas -dFPC_ARMEL -O- -dFPC_ABI_EABI -CfVFPv3 -Cparmv7  -CaEABI pmain 

using fpc svn fixes_2_6 Revision: 22520

G++ calls as with -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5
and is configured with 
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7l-unknown-linux-gnueabihf/4.7.1/lto-
wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: /build/src/gcc-4.7-20120721/configure --prefix=/usr --
libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --
infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-
languages=c,c++,fortran,lto,objc,obj-c++ --enable-shared --enable-
threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-
time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-
cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --
enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-
ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --
disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-
checking=release --host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-
linux-gnueabihf --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
Thread model: posix
gcc version 4.7.1 20120721 (prerelease) (GCC)

$ fpc -i
Free Pascal Compiler version 2.6.1

Compiler Date  : 2012/10/03
Compiler CPU Target: arm

Supported CPU instruction sets:
  ARMV3
  ARMV4
  ARMV5
  ARMV6
  ARMV7
  ARMV7M
  CORTEXM3

Supported FPU instruction sets:
  SOFT
  LIBGCC
  FPA
  FPA10
  FPA11
  VFPV2
  VFPV3

Supported ABI targets:
  DEFAULT
  SYSV
  AIX
  EABI
  ARMEB


Platform: Beaglebone
$ cat /proc/cpuinfo 
Processor   : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 498.89
Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: am335xevm
Revision: 
Serial  : 

Kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[den . jean]

Hello,

> The hard float abi is not supported in fixes_2_6, and probably never
> will be. Additionally, you cannot compile programs for the hard
> float abi using a regular eabi compiler. You have to compile the ARM
> compiler with -dFPC_ARMHF.
I tried fixes_2_6 first as the idea was to use lazarus Qt and I
had problems with both lazarus and Qt binding using fpc 2.7
I only found FPC_ARMEL defined in fpc sources
and the VFPV3 in `fpc -i` made me believe this was how you define hardfloat.
To me all this is still a bit confusing.

I already find out reading 
http://lists.freepascal.org/lists/fpc-devel/2012-March/028576.html
that ARMEL does not include hardfloat calling convention and that
a new -dFPC_ARMHF has been defined. 

So I used trunk and now I am able to create a cross compiler
that seems to generate correct code. I had a small test program 
that calls a function with float arguments in a small test library.
This test program now works.

Next arm question :-)
Currently I am unable to generate a native
compiler, I do things like (from memory, not in front of beaglebone)
cd compiler
make cycle PP=old armel ppcarm 'all options like -dFPC_ARMHF -Cf.. -Ca.. -Cp.. '
this creates a ppcarm_hf and a armhf rtl
cd ..
make all install PP=previous ppcarm_hf
If use the ppcarm_hf as i noted by substituting as and ld with scripts,
that not the right hardfloat parameters were passed to as with PP=old armel 
ppcarm
This stops at compiling somewhere (fpmake if I remember well)
I understand that compiling trunk with trunk and on arm is not a good
idea. On top of that, this is very slow.
How can I avoid above. I would like to create it from cross.

But when I do 
make crosszipinstall it gives me a cross ppcrossarm (i386 executable)
and arm rtl/packages.
How can I generate a corresponding (to arm rtl/packages) ppcarm (arm executable)
from i386 so that i can copy over a full fpc installation to the arm board?

Kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[den . jean]

Hi,

> After the crosszipinstall, compiler/ppcarm (not installed, but in the
> source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have missed that ? 
Thanks for the quick responses.

Kind regards,

Den Jean



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
> > After the crosszipinstall, compiler/ppcarm (not installed, but in the
> > source directory) is the native ARM compiler.
> 
> I looked there with `file pp* `
> How could I have missed that ? 

Well I could check now and it is not there

make crosszipinstall CPU_TARGET=arm CROSSOPT="-Aas -dFPC_ARMHF -O- -CaEABIHF -
CfVFPV3_D16 -Cparmv7a" BINUTILSPREFIX=arm-linux-gnu- INSTALL_PREFIX=/usr

Is there a manual make command to get it

Kind regards,

Jan



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 20:40:23 Florian Klämpfl wrote:
> At least -dFPC_ARMHF shouldn't be a cross opt.
Thx for the info

extracts Makefile.fpc:


#
# Cycle targets

# 3. Source CPU <> Target CPU
#First source native compiler
#Second cross compiler
#Third target native compiler (skipped for cross installation)
#
#



So with 
make all CPU_TARGET=arm CROSSOPT="-Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7a" 
BINUTILSPREFIX=arm-linux-gnu- INSTALL_PREFIX=/usr

 I do get an arm native compiler

Kind regards,

Jan

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 21:09:55 Thomas Schatzl wrote:
> I put an armhf snapshot from today at
> http://members.yline.com/~tom_at_work/fpc-2.7.1.arm-linux.tar.gz . I
I was going to do the same thing :-)
Do you have more experiemce with fpc and armhf, any problems 
you are aware of? 
> will see if I can figure out how to do automatic uploads from the fpc
> testsuite runs on a daily basis.
> Btw, native compilation of a snapshot/zipinstall takes ~11mins on that
> arm machine - it's not that slow
If you are trying all compilation options, it is. 
I also only have 128MB. If do not know if it affects fpc compilation,
but I am sure it affects c++ qt4pas compilation.

Does this mean you can compile the fpc trunk compiler natively ?
I will try now anyhow using the cross generated one.

I will also adapt the qt4 binding so that it compiles again with fpc 2.7.1
and compile it for arm.

Kind regards,

Jan
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
> Basically the difference between armel and armhf are
>   - fpc cannot create valid armhf shared libraries
> 
> Other problems common to both (just from interpreting the testsuite
> results, filtering known failing tests):
>   - there are issues with threading/synchronization (test machine is a
> quad-core box, previous test machine was single core where as usual such
> problems don't show up)
>   - fpu exceptions/setting fpu exception mask seem to not work
>   - some problems with fpc resources
Thx for the info

In the Qt binding I need to do this 
SetExceptionMask([exDenormalized,exInvalidOp,exOverflow,exPrecision,exUnderflow,exZeroDivide]);
because of Qt C++ not allowing such exceptions

is this a problem ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
> Yes. Probably one of the first milestones for a new arch is self-hosting
> (if possible at all).

Ahum it always fails over here

time make OPT='-dFPC_ARMHF -Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7a' clean 
all


units_bs/arm-linux/fpmkunit.s:28079: Rd and Rm should be different in mul
make[3]: Leaving directory `/home/jan/svn/fpc/packages/fpmkunit'
/home/jan/svn/fpc/compiler/ppcarm fpmake.pp -n -
Fu/home/jan/svn/fpc/packages/fpmkunit/units_bs/arm-linux -
Fu/home/jan/svn/fpc/rtl/units/arm-linux  -dFPC_ARMHF -Aas -O- -CaEABIHF -
CfVFPV3_D16 -Cparmv7a
fpmake.pp(34) Error: Can't call the assembler, error -9 switching to external 
assembling
fpmake.pp(34) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [fpmake] Error 1
make[2]: Leaving directory `/home/jan/svn/fpc/packages'
make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `/home/jan/svn/fpc'
make: *** [build-stamp.arm-linux] Error 2

real17m1.938s
user14m36.140s
sys 1m31.230s

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Thursday 04 October 2012 23:18:43 Thomas Schatzl wrote:
> Just checked, processor info (-Cparmv7a) is not passed to the assembler.
> Try "-Cparmv7" - only then --march=armv7-a is passed correctly
yep.

but make still fails 

/home/jan/svn/fpc/compiler/ppcarm src/fpmkunit.pp -n 
-Fu/home/jan/svn/fpc/rtl/units/arm-linux -Fu/home/jan/svn/fpc/packages/paszlib 
-Fu/home/jan/svn/fpc/packages/fcl-process -Fu/home/jan/svn/fpc/packages/hash 
-FUunits_bs/arm-linux -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src  
-Fi../fcl-process/src/unix -Fu../fcl-process/src -Fi../fcl-process/src/linux 
-Fi../fcl-process/src/dummy -dFPC_ARMHF -Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7
make[3]: Leaving directory `/home/jan/svn/fpc/packages/fpmkunit'
/home/jan/svn/fpc/compiler/ppcarm fpmake.pp -n 
-Fu/home/jan/svn/fpc/packages/fpmkunit/units_bs/arm-linux 
-Fu/home/jan/svn/fpc/rtl/units/arm-linux  -dFPC_ARMHF -Aas -O- -CaEABIHF 
-CfVFPV3_D16 -Cparmv7
fpmake.pp(34) Error: Can't call the assembler, error -9 switching to external 
assembling
fpmake.pp(34) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [fpmake] Error 1
make[2]: Leaving directory `/home/jan/svn/fpc/packages'
make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `/home/jan/svn/fpc'
make: *** [build-stamp.arm-linux] Error 2


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Friday 05 October 2012 00:12:46 Thomas Schatzl wrote:
> Let's start from the beginning. What's your starting compiler? 2.7.0 I
> guess? (which is the only option anyway for hardfloat).
on i386 i used cross binutils from fedora packages 
cross-binutils-common.noarch  2.22.52.0.3-1.fc17 
cross-gcc-common.noarch  4.7.1-0.1.20120606.fc17   
fpc 2.7.1 latest svn

> Binutils/gas
on arm

$ fpc -v
Free Pascal Compiler version 2.7.1 [2012/10/04] for arm
created from on i386 svn trunk using crosszip 

$ as --version
as called with --version
GNU assembler (GNU Binutils) 2.22.0.20120323


> Are you sure (the correct) gas is in the path? (It's strange because the
correct ?
> compilation before found correct gas; afaik fpmake/packages are only
> compiled at the end)

> Can you also try a "make distclean"? And check if the packages directory
> does not contain any fpmake executables, object or ppu files afterwards;
already removed them by hand beforing this (make clean in that dir,
stil had 1 .o and fpcmake (-> delp . and rm fpmake)
> if so, please remove them. Fpmake sometimes gets messed up if parts of a
> previous compilation are still there. Further, at the moment, fpc
> silently allows linking of mixed armel and armhf object files, which
> does not work.
thx for info 
> > fpmake.pp(34) Fatal: There were 2 errors compiling module, stopping
> > Fatal: Compilation aborted
> > make[2]: *** [fpmake] Error 1
> > make[2]: Leaving directory `/home/jan/svn/fpc/packages'
> 
> Can you enter the "/home/jan/svn/fpc/packages"  directory and issue the
> following command (maybe before doing a distclean):
too late, nice to know 
> /home/jan/svn/fpc/compiler/ppcarm fpmake.pp -n
> -Fu/home/jan/svn/fpc/packages/fpmkunit/units_bs/arm-linux
> -Fu/home/jan/svn/fpc/rtl/units/arm-linux -dFPC_ARMHF -Aas -O- -CaEABIHF
> -CfVFPV3_D16 -Cparmv7 -s
> 
> (note the additional "-s" param) and paste the resulting ppas.bat after
> it fails here? The line that invokes gas should use the correct gas. And
> it should have a correct "--march=armv7-a" parameter.
I already had replaced as with a shell script that shows me the passed 
parameters:
e.g now I have:
as called with -mfloat-abi=hard -meabi=5 -march=armv7-a -mfpu=vfpv3-d16 -o 
arm/units/arm-linux/pp.o arm/units/arm-linux/pp.s
> Thomas

thx 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Friday 05 October 2012 00:12:46 Thomas Schatzl wrote:
> (note the additional "-s" param) and paste the resulting ppas.bat after
> it fails here? The line that invokes gas should use the correct gas. And
> it should have a correct "--march=armv7-a" parameter.

$ cat ppas.sh 
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Assembling fpmake
/usr/bin/as -mfloat-abi=hard -meabi=5 -march=armv7-a -mfpu=vfpv3-d16 -o 
fpmake.o fpmake.s
if [ $? != 0 ]; then DoExitAsm fpmake; fi
rm fpmake.s
echo Linking fpmake
OFS=$IFS
IFS="
"
/usr/bin/ld   --dynamic-linker=/lib/ld-linux-armhf.so.3  --gc-sections  -L. -o 
fpmake link.res
if [ $? != 0 ]; then DoExitLink fpmake; fi
IFS=$OFS



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Friday 05 October 2012 12:14:23 Thomas Schatzl wrote:

> assembler was configured for a target of `arm-linux-gnueabihf'."

$ as --version
as called with --version
GNU assembler (GNU Binutils) 2.22.0.20120323
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `armv7l-unknown-linux-gnueabihf'.
[jan@alarm ~]$ 

 > Given it's still the "Error -9" that is the problem, can you manually
> invoke gas using the line from the ppas.sh script?
manually executed with strace and the .o was created
without errors and exited with value 0
so why does fpc always thinks it is not zero
and why if i continue make without clean
does it seem that it starts all over again 
with c++ make, it continuous on that file
> Honestly, I am somewhat out of ideas here.
me too
also with c++ on board compilation I have
g++ exiting with internal errors, but when I 
restart make it continues for some time fine
and then internal error again on another later
file, it is version g++ (GCC) 4.7.1 20120721 (prerelease), 
I am not too fond of too new gccs, always problems...

I will install another distro (now arch linux) too see if it is related
to too bleeding edge.

Thanks already for all the help.

Kind regards,

Jan



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Friday 05 October 2012 01:18:59 Den Jean wrote:
> if [ $? != 0 ]; then DoExitLink fpmake; fi
scripts never ly, there was no swap partition and little
memory -> accidents bound to happen.

I now have 256MB and a swap file.
I can compile and run lazarus qt.
Qt4 Binding V2.6RC2 for BeagleBoard:
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.6RC2/

However I still cannot compile fpc natively.

These are the errors when trying
to do make cycle using the ppcarm you provided
for fpc svn latest trunk
make cycle  OPT='-dFPC_ARMHF -Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7' 
PP=~/ppc_armhf

system.inc(1106,3) Note: Local variable "prevaddr" is assigned but never used
text.inc(1789,14) Warning: Implicit string type conversion from "AnsiString" 
to "UnicodeString"
text.inc(2013,44) Warning: Implicit string type conversion with potential data 
loss from "UnicodeString" to "AnsiString"
arm.inc(26,3) Note: Local variable "cpu_has_edsp" is assigned but never used
Assembling system
as called with -mfloat-abi=hard -meabi=5 -march=armv7 -mfpu=vfpv3-d16 -o 
../../rtl/units/arm-linux/system.o ../../rtl/units/arm-linux/system.s
../../rtl/units/arm-linux/system.s: Assembler messages:
../../rtl/units/arm-linux/system.s:14: Error: lo register required -- `stmfd 
r13!,{r4,r11,r12,r14,r15}'
../../rtl/units/arm-linux/system.s:15: Error: lo register required -- `sub 
r11,r12,#4'
../../rtl/units/arm-linux/system.s:17: Error: lo register required -- `strb 
r0,[r11,#-48]'
../../rtl/units/arm-linux/system.s:18: Error: lo register required -- `str r2,
[r11,#-56]'
../../rtl/units/arm-linux/system.s:19: Error: lo register required -- `str r3,
[r11,#-52]'
../../rtl/units/arm-linux/system.s:33: Error: lo register required -- `strb 
r0,[r11,#-64]'
../../rtl/units/arm-linux/system.s:34: Error: lo register required -- `ldrsb 
r0,[r11,#-64]'
../../rtl/units/arm-linux/system.s:36: Error: Thumb does not support 
conditional execution
../../rtl/units/arm-linux/system.s:37: Error: Thumb does not support 
conditional execution

Kind regards,

Jan

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Hardfloat

[Den Jean]

On Monday 08 October 2012 21:05:15 Thomas Schatzl wrote:
> That's why previously I told you to use -Cparmv7 (it did not work with
> -Cparmv7a); but this has changed.
It works now.
> Sorry for the confusion,
Thank you very much again for the help.

Kind regards,

Jan

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] order of tar parameters during make zipinstall

[Den Jean]

Hi,

make zipinstall does not work for my busybox tar

the call to tar is made like this: 
/bin/tar cfvz /svn/fpc/fpc-2.5.1.arm-linux.tar.gz *
but my system tar wants the option 'f' right in front of the target filename.

Makefile contains:
ZIPCMD_ZIP:=$(TARPROG) cf$(TAROPT) $(ZIPDESTFILE) *
   ^^^
# tar -v
BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso26+0m5) multi-call binary
Usage: tar -[czxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE(s)]...

If someone agrees to fix this, I'll make a bug report

kind regards,

Den Jean



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] order of tar parameters during make zipinstall

[Den Jean]

On Saturday 15 May 2010 22:35:23 Den Jean wrote:
> If someone agrees to fix this, I'll make a bug report
> 
done 
http://bugs.freepascal.org/view.php?id=16504
including patch proposal
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Armel problems

[Den Jean]

Hi,

I am investigating why Qt on armel has problems.

I think that one of the problems is 
that when c-functions are called from 
pascal that the parameters are not passed 
correctly (or not as I expected and accommodated for).

I noticed that when the parameter is a 
""
like @MyMethod  (method of a class, with a cdecl decoration)
that the c-functions do not get the correct addresses.

When I change the pascal definition of the external c-function
and replace the "procedure () of object cdecl;" with
2 pointer parameters (MethodFunc,MethodData:Pointer) and
use (@TClass.MyMethod,Self) ... well then it works fine.

In the C-library I expect to receive a struct 
that I declared like this:
typedef struct {
  void *func;
  void *data;
} QHook;

Pascal:
type QAbstractButton_clicked2_Event = procedure () of object cdecl;
// when c-function declared like this
procedure QAbstractButton_hook_hook_clicked2(handle: QAbstractButton_hookH; 
hook: QAbstractButton_clicked2_Event); cdecl; external Qt4PasLib name 
'QAbstractButton_hook_hook_clicked2';
// then this call does not work
QAbstractButton_hook_hook_clicked2(Hook,@MyMethod);

// when c-function declared like this
procedure testhook(handle: QAbstractButton_hookH; HookFunc,HookData:Pointer); 
cdecl; external Qt4PasLib name 'QAbstractButton_hook_hook_clicked2';
// then this works in constructor of TMyClass
testhook(Hook,@TMyClass.MyMethod,self)

fpc: latest svn, compiled with -dFPC_ARMEL
Code:{$mode objfpc}{$H+}

kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Armel problems

[Den Jean]

On Monday 17 May 2010 22:22:13 Den Jean wrote:
> Hi,
> 
> I am investigating why Qt on armel has problems.
> 
> I think that one of the problems is
> that when c-functions are called from
> pascal that the parameters are not passed
> correctly (or not as I expected and accommodated for).
> 
On Tuesday 18 May 2010 10:17:27 Michael Schnell wrote:
> Does the compiler digest this ?
> 
> Up till now I thought it's impossible to use any common object ABI
> between Pascal and C++, so that any C function needs to be called by
> Pascal using a "flattened" non-Object based interface, because the
> Pascal and C++ object models are too different to use common objects
> with both languages.
> 

Note how I say c-functions and not c++ functions. Only a C ABI
is guaranteed, this is why all languages can interface with C
but not with C++ or Java. I lack detailed knowledge of that ABI
so the FPC devels may have to correct me on how that method
struct will be passed, but I guess it should be by value. The 
alignment is probably not an issue with 2 struct members with the
size of a pointer.


 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Armel problems

[Den Jean]

On Wednesday 19 May 2010 10:18:53 Michael Schnell wrote:
> If the compiler does digest this, the meaning supposedly is that the
> procedure gets an additional, supposedly first, parameter (hidden in
> Object Pascal, open in C, that is the self pointer of the instance. If
> the C programmer knows how to deal with the Pascal object model which of
> course he can, as FPC is open source, he in fact can make use of this.
> 
The FPC Qt4 binding is made to let FPC interface with Qt4 via
flattened c-functions. C++ signals can be hooked to
FPC object method. I choose to support methods, because if
you support methods, you also support simple procedures,
just provide zero for the self parameter when installing the 
hook.

I made a demo program of the bug, 
using the style of one of the fpc test suite program tcalext2.pp

http://bugs.freepascal.org/view.php?id=16520


kind regards,

Den Jean



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Armel problems

[Den Jean]

On Sunday 23 May 2010 21:51:17 Den Jean wrote:
> I made a demo program of the bug, 
> using the style of one of the fpc test suite program tcalext2.pp
> 
> http://bugs.freepascal.org/view.php?id=16520

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Armel problems

[Den Jean]

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 N900 will stay on maemo and will not be meego.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] native fpc on arm

[Den Jean]

Hi,

I noticed this change log on fpc svn: 
  florian 15472 
  * don't build a native compiler for embedded targets
I sometimes build a native fpc on N900,
(sometimes because it takes some time)
Will this affect me if I do a 'svn up fpc' on the N900 ?
When is a target considered embedded by the makefile? 

native build cmd line is:
make clean all install PREFIX=/opt OPT='-gl -dFPC_ARMEL'

kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] native fpc on arm

[Den Jean]

On Tuesday 22 June 2010 22:27:59 Florian Klämpfl wrote:
> Devices without any operating system, i.e. mainly microcontrollers.
> 
thx Jonas and Florian, updating and compiling now.

fpc on arm related question,

when installing fpc, I need to install to /opt, 
because /opt resides on a partition with enough free space.
(This is normal on N900, it is called optify, do not know
why /opt/bin is not in path.)

Then I need to symlink from /opt/bin/ to /usr/bin/
For now I just symlinked all fpc created files with a long script,
but to shorten any upcoming instructions, which ones 
are needed to just compile fpc and lazarus. I know 
h2pas is not needed, but which ones are used for
compiling fpc and lazarus. What is 'mkarmins' (creates 
some files and gives runtime error)

Files linked now:
/opt/lib/fpc/2.5.1/ppcarm
and /opt/bin:

Files = [
'bin2obj',
'chmcmd', 
'chmls',  
'data2inc',
'delp',
'fd2pascal',
'fp',   
'fpc',  
'fpclasschart',
'fpcmake', 
'fpcmkcfg',
'fpcres',  
'fpcsubst',
'fpdoc',   
'fppkg',   
'fprcp',   
'grab_vcsa',   
'h2pas',   
'h2paspp', 
'makeskel',
'mkarmins',
'mkx86ins',
'plex',
'postw32',
'ppdep',
'ppudump',
'ppufiles',
'ppumove',
'ptop',
'pyacc',
'rmcvsdir',
'rstconv',
'unitdiff'
]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] native fpc on arm

[Den Jean]

On Tuesday 22 June 2010 23:24:28 Florian Klämpfl wrote:
> > (This is normal on N900, it is called optify, do not know
> > why /opt/bin is not in path.)
> 
> Just insert /opt/bin into the path?
> 
this would mean editing a system file
like /etc/profile, I'd like to avoid that 
in instructions, as apt-get upgrade might 
not apply updates to modified system config 
files as /etc/profile (I am not sure though, I am more familiar 
with urpmi that saves config files to *.new -> 
meaning updates to config files are lost in order to 
preserve own  modifications.)

I you look at the /usr/bin after a clean reflash,
it is full of links to several opt directories, apparently
symlinking is the proper way.

is just ppcarm, fpc, fpcmake,fpcres enough ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] native fpc on arm

[Den Jean]

On Tuesday 22 June 2010 22:45:59 Den Jean wrote:
> are needed to just compile fpc and lazarus. I know 
> 

when trying to compile lazarus using native arm on N900,
I get the errors below. There is no file lazarus.or (strange extension ??)

I manually tried some tests from svn/fpc/tests/test/units/system:
(tres.pp,tres2.pp,tres2ext.pp,tres3.pp,tres3ext.pp,tres4.pp,tresext.pp)
and checked the return value, all tests succeeded. 

Someone any idea ?


Compiling idecmdline.pas
Assembling idecmdline
Assembling main
Assembling lazarus
Compiling resource ../units/arm-linux/lazarus.or
Error: Wrong token symbol: INLINE expected but Left found (at 1,2339, stream 
offset 002D)
lazarus.pp(123,42) Error: Error while compiling resources
lazarus.pp(123,42) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [lazarus] Error 1
make[2]: Leaving directory `/media/mmc1/svn/lazarus/ide'
make[1]: *** [ide] Error 2
make[1]: Leaving directory `/media/mmc1/svn/lazarus/ide'
make: *** [ide] Error 2
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] native fpc on arm

[Den Jean]

On Thursday 24 June 2010 11:37:18 Florian Klaempfl wrote:
> > is just ppcarm, fpc, fpcmake,fpcres enough ?
> 
> Does it hurt to have more?
not technically, as mentioned above I would
prefer not to have to instruct to create too many links.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] native fpc on arm

[Den Jean]

On Wednesday 23 June 2010 01:49:29 Den Jean wrote:
> when trying to compile lazarus using native arm on N900,
> I get the errors below. There is no file lazarus.or (strange extension ??)
> 
on i386 the file lazarus.or exists after compilation,
copying it to arm device lazarus svn does not help
manually compiling fpcres lazarus.res to lazarus.or works 
(well I get a lazarus.or different from the i386 svn)
continuing compilation with a manually created lazarus.or does not work.

any idea would be welcome :-)

 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC and Dicom

[Den Jean]

On Sunday 27 June 2010 16:27:09 Leonardo M. Ramé wrote:
> Hi, is anyone working on a Dicom library for FPC?. It would be nice to have
>  an "fcl-dicom" library, based, for example in an object pascal version of
>  DCMTK (a C++ library http://www.dcmtk.org/dcmtk.php.en).
> 
http://wiki.freepascal.org/Lazarus_Application_Gallery#MRIcron
first google result of free pascal dicom
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] mstackrealign

[Den Jean]

Hi,


http://bugs.freepascal.org/view.php?id=17384
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

can a C-ABI expert enlight us on this ABI mess.
Does this also effect calling in general of C-functions from Free Pascal.

regards,

Den Jean



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] mstackrealign

[Den Jean]

Does this also effect calling in general of C-functions from Free Pascal.


Afaik, the Linux/i386 abi only mandates 4 byte stack alignment. That  
means that any function requiring a higher stack alignment has to  
realign the stack. That's what the new -mstackrealign gcc option does.


I am puzzled why some many projects seem to suffer from this (google),
Is it not just a matter of adding  __attribute__ ((force_align_arg_pointer))
to the functions with sse calls? Instead of compiling the whole code with 
-mstackrealign ?

The following extract from qglobal.h shows me it is only considered a problem 
on windows ?!

//defines the type for the WNDPROC on windows
//the alignment needs to be forced for sse2 to not crash with mingw
#if defined(Q_WS_WIN)
#  if defined(Q_CC_MINGW)
#define QT_ENSURE_STACK_ALIGNED_FOR_SSE __attribute__ 
((force_align_arg_pointer))
#  else
#define QT_ENSURE_STACK_ALIGNED_FOR_SSE
#  endif
#  define QT_WIN_CALLBACK CALLBACK QT_ENSURE_STACK_ALIGNED_FOR_SSE 
#endif



When grepping the Qt source, I do see this attribute popping up in windows only 
files
like qdnd_win.cpp, so I am still puzzled why then with these precautions by Nokia Qt, 
it still does not work.



regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Const optimization is a serious bug

[Den Jean]

On Friday 08 July 2011 12:05:02 Jonas Maebe wrote:
> The main problem here is that FPC's exception handling is based on  
> setjump/longjump. This technique has a relatively high overhead for  
> "try", but low overhead when an exception actually occurs (of course,  
> since exceptions are supposed to happen only exceptionally, that's not  
> a really good selling point). The main reason we use it is because  
> it's easy to implement.
> 
> A better approach would be to use SEH-based exception handling (which  
> has no overhead at all for "try", and a high overhead in case an  
> exception occurs), but that woud require
I strongly prefer the current situation where the occurrence of 
exceptions does not incur an important extra overhead compared to
the nominal situation.

In the type of applications I write (Air Traffic Control Radar Screens,
Electronic Strips and System Interfaces) it is considered good practice 
to catch exceptions in every procedure because it is a must that 
the applications always survive and continue to provide the remaining,
not affected services.(graceful degradation principle)

I do not want any discussions whether catching exceptions is good or not.
If someone thinks otherwise, I do not care at all, do not bother me or 
this mailing list. 

However what is imperative is that when many exceptions occur, there should 
not be a mayor performance penalty. One of the reasons I use languages such 
Pascal and Ada for this type of applications, is that they are very fast, 
(though I also have foreseen code to shutdown services with too many problems 
in a given time frame). So I beg you to leave exceptions as is (please :-)). 

kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Typo in unistdh.inc

[Den Jean]

Hi,

1) sysconf:
could someone please fix sysconf in unistdh.inc.
The library name is not correct

packages/base/libc/unistdh.inc:function sysconf (__name : longint) : longint; 
cdecl; external clib name 'syconf';


The compile error is typically :

 In function `START_SESSION':
SYS_UTIL.pas:329: undefined reference to `syconf'

The rest is nice to have...

2) PUserContext: 

   It would be nice to add the the following type definion for more Kylix 
compatibility
   type PUserContext = ^TUserContext;
  grep -> ./packages/base/libc/sucontexth.inc:  TUserContext = ucontext_t;


3) sigaction:
 It would be nice to fix the definition of sigaction. If a libc function is 
defined 
 to take pointers as an argument, it only looks cleaner to define the 
parameter as a var,
 but mostly it is better to define it with a pointer, this way it remains 
possible to pass nil as parameter.
 If passing nil does not make sense, using var is ok. All this only to 
avoid too many IFDEFS in code that
 is to be Kylix and FPC compatible.

 So I prefer (Kylix extract)

function sigaction(SigNum: Integer; Action: PSigAction; OldAction: PSigAction): 
Integer;

   instead of 

./packages/base/libc/signalh.inc:function sigaction(__sig:longint; Const act: 
_sigaction; Var oldact: _sigaction):longint;cdecl;external clib name 
'sigaction';

4) setrlimit:

Here again Kylix has another definition and more logical (you cannot omit the 
rlimit)
It would be nice (Kylix compatibility) to have the Kylix type of definition.

fpc:
function setrlimit(__resource:__rlimit_resource_t; 
__rlimits:Prlimit):longint;cdecl;external clib name 'setrlimit';

Kylix:
function setrlimit (__resource: __rlimit_resource_t; const __rlimits: TRLimit): 
Integer; cdecl;

5) I need many more ifdefs, but I notice sometimes that it is better in FPC, 
then I just add an IFDEF and shut up.


kind regards,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Can't declare procedure as EXTERNAL

[Den Jean]

Hi, 

I am porting CLX to FPC.

Some time ago, when I created a Qt/Embedded binding for FPC,
Qt.pas did not compile anymore due to some changes in FPC. 
The error was:
Can't declare procedure as EXTERNAL

See also:
http://www.nl.freepascal.org/lists/fpc-pascal/2004-December/007738.html

I created a tool to move the declarations to the interface, 
but now I notice that FPC does not give an error anymore. 
Is the problem solved or should I still for safety move the declarations 
to the interface section ?

kind regards,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fpc and Ipaq

[Den Jean]

Hi,

you might also look at:

 http://users.pandora.be/Jan.Van.hijfte/qtforfpc/qtedemo.html

This webpage is about a Qt/Embedded binding for FreePascal (FPC)
The source code of a small demo program is provided as well

You can view an animated screenshot of the program in action on a Zaurus:

http://users.pandora.be/Jan.Van.hijfte/qtforfpc/screenshots.html

The FPC (FreePascal) binding for Qt and Qt/Embedded and the source 
of the demo are also available on Sourceforge:

   http://sourceforge.net/projects/qtforfpc/

The webpage contains all the necessary links 
needed for arm cross development with FreePascal.

And last but not least, there is a page dedicated to the setup of
a FreePascal cross compilation setup (including Qt/Embedded and qvfb)


kind regards,

Den Jean


On Tuesday 05 April 2005 08:23, Uberto Barbini wrote:
> Does anyone have experience with fpc and linux on handhelds?
> May the 6th, I'll show fpc at a Delphi workshop, and I'll concentrate on
> thinks Delphi doesn't do.
> I can borrow an Ipaq with linux and opie, and I like to show some fpc
> application on it.
>
> Bye Uberto
>
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] FPC CVS Fatal: Internal error 200108222

[Den Jean]

Hi,

since some days, CLX does not compile anymore
with a fresh FPC from CVS 

compiler output:
...
...
QComCtrls.pas(3358,37) Note: Values in enumeration types have to be ascending
QComCtrls.pas(4154,14) Warning: Local variable "Method" does not seem to be 
initialized
QComCtrls.pas(4824,3) Note: Local variable "R" is assigned but never used
QComCtrls.pas(4854,18) Fatal: Internal error 200108222


kind regards,

Den Jean


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC CVS Fatal: Internal error 200108222

[Den Jean]

On Thursday 07 April 2005 19:48, Peter Vreman wrote:
>
> Can you make a short example that fails. There is no CLX code in our cvs
> to reproduce it.


I know I should, I tried but similar code does not give an internal error.
I have gtarred everything and put it here

http://users.pandora.be/Jan.Van.hijfte/qtforfpc/internal_error_200108222.tar.gz

use the compile script compile.bash to setup the environment correctly


kind regards,

Den Jean


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC CVS Fatal: Internal error 200108222

[Den Jean]

On Thursday 07 April 2005 22:01, Den Jean wrote:
> On Thursday 07 April 2005 19:48, Peter Vreman wrote:
> > Can you make a short example that fails. 
>
> I have gtarred everything and put it here
>


I guess you fixed it because the internal error 
is gone and I see this in CVS: 

* remove multiple pass2 calls. It is not supported anymore by all nodes
(ttempcreatenode)


thx,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] passing a double parameter on arm

[Den Jean]

Hi,

There seems to be an ARM ABI bug with passing doubles on arm.

When I call a C-procedure of a library using a c-program, it works.

When I call the C-procedure using a fpc ARM program it doesn't work.

Here is an example:

definition of the c-procedure to call
void QLCDNumber_display2(QLCDNumberH handle, double num);

use of the c-procedure in a c-program that works fine:
QLCDNumber_display2(lcd,142.3);

use of the c-procedure in a pascal program (does not work)
procedure QLCDNumber_display(handle: QLCDNumberH; num: Double); cdecl; 
overload;  external QtShareName name 'QLCDNumber_display2';
QLCDNumber_Display(lcd,142.3);


but this trick works:
procedure QLCDNumber_display_trick(handle: QLCDNumberH; hinum,lonum:integer); 
cdecl; overload;  external QtShareName name 'QLCDNumber_display2';
type
  TDoubleRec = record
Hi : integer;
Lo : integer;
  end;
  PDoubleRec = ^TDoubleRec;

. 
var
  d : double;
  p : PDoubleRec; 
..
d:=142.3;   
p:=PDoubleRec(@d);
QLCDNumber_Display_trick(l,p^.hi,p^.lo);

I used :
Free Pascal Compiler version 2.0.1 [2005/07/21] for arm


kind regards,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] passing a double parameter on arm

[Den Jean]

On Thursday 21 July 2005 10:15 pm, Florian Klaempfl wrote:

> Tried to fix it in 2.1.1 (untested).
> 

I tested it and it works now,
Big thank you.
I used svn revision 728

...
Free Pascal Compiler version 2.1.1 [2005/07/23] for arm
Copyright (c) 1993-2005 by Florian Klaempfl
/usr/lib/fpc/2.1.1/ppcarm [options]  [options]
..

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] __stkptr

[Den Jean]

Hi,

with latest fpc 2.1.1 I get:

cat test.pas
program test; begin writeln('test'); end.
[EMAIL PROTECTED] ppc386 test
Free Pascal Compiler version 2.1.1 [2006/02/23] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
Linking test
/usr/lib/fpc/2.1.1/units/i386-linux/rtl/system.o: In function `SYSTEM_init':
system.pp:(.text+0x169e8): undefined reference to `__stkptr'
test.pas(1,38) Error: Error while linking

kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Can't resolve www.freepascal.org

[Den Jean]

On Sunday 19 February 2006 07:14 pm, [EMAIL PROTECTED] wrote:
> it seem's there's something with the webpage

not for me

tracepath www.freepascal.org
... telenet ...
 5:  versatel.bnix.net (194.53.172.115)   asymm  7  30.548ms
 6:  62.58.254.133 (62.58.254.133)asymm 11  35.447ms
 7:  62.58.254.145 (62.58.254.145)asymm  9  27.423ms
 8:  62.58.126.196 (62.58.126.196)asymm 10  29.530ms
 9:  unlabelled.versatel.net (62.58.126.46)   asymm 11  39.924ms
10:  cust198-193.dsl.versadsl.be (62.166.198.193) asymm 12  50.123ms
11:  cust198-202.dsl.versadsl.be (62.166.198.202) asymm 13  51.678ms 
reached
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] __stkptr

[Den Jean]

On Friday 24 February 2006 03:25 am, Peter Vreman wrote:
> Make sure you have updated all files from svn. The __stkptr is defined in
> the loader files named *ptr*.o
I did
svn update fpc
now I did
rm -fr fpc
svn checkout http://svn.freepascal.org/svn/fpc/trunk fpc
cd fpc
make PREFIX=/usr clean
make PREFIX=/usr all
make PREFIX=/usr install
ln -fs /usr/lib/fpc/2.1.1/ppc386 /usr/bin/

svn update gives:
At revision 2674

still same __stkptr problem.

As i have problems with fpc 2.0.2  I compile fpc with 2.0.0

The problems with 2.0.2 are that some calls to libqt4intf
fail (exception div by zero) and not with 2.0.0
I still need to trim down a sample program to be able to
report the bug, but is ok to compile 2.1.1 with 2.0.0 ?

BTW the dll fails for a call to this
void QPainter_drawLine3(QPainterH handle, int x1, int y1, int x2, int y2)
{
((QPainter *)handle)->drawLine(x1, y1, x2, y2);
}
if i printf the parameters within this dll, they are fine (no 
reference/value/byteswap problem but something else)

another call fails after a while, something extra on the stack ???

with fpc 2.0.0 everything works fine, even when the programs runs for a longer 
time.

kind regards,

Den Jean


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] __stkptr

[Den Jean]

On Friday 24 February 2006 06:14 am, Peter Vreman wrote:
> Fixed
[EMAIL PROTECTED] fpc]# svn update
At revision 2675.

ppc386 test.pas
Free Pascal Compiler version 2.1.1 [2006/02/24] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
Linking test
/usr/lib/fpc/2.1.1/units/i386-linux/rtl/system.o: In function `SYSTEM_init':
system.pp:(.text+0x169e8): undefined reference to `__stkptr'
test.pas(1,38) Error: Error while linking

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] __stkptr

[Den Jean]

On Friday 24 February 2006 06:55 am, Peter Vreman wrote:
> Check with objdump if dllprt0.o exports the __stkptr.

objdump -t dllprt0.o | grep stkptr
 g O .bss   0004 __stkptr

so i checked further and i found that just doing 
ln -fs /usr/lib/fpc/2.1.1/ppc386 /usr/bin/
is not enough to switch fpc versions, 
because the fpc.cfg from fpc-2.0.0-2mdk.i586.rpm contained 
-Fu/usr/lib/fpc/2.0.0/units/$fpctarget
-Fu/usr/lib/fpc/2.0.0/units/$fpctarget/*
-Fu/usr/lib/fpc/2.0.0/units/$fpctarget/rtl

I removed these lines and all ok.
big apologies 

But 2.1.1 gives me the same problems as with 2.0.2
The Qt4 binding does not work. They told
me that lazarus requires 2.0.2, so it is a problem
that my binding does not work with 2.0.2

So I will upload a demo program that demonstrate the problem


kind regards,

Den Jean









___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] MSEide + MSEgui -> FPC Wiki

[Den Jean]

Hi,

would the FPC team mind if we'd use the FPC Wiki to
document the use of the MSEGui library and the Ide ?

It is completely written in pascal, voiding the need
to endlessly update bindings to gtk/qt etc :-)

kind regards,

Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Den Jean]

Hi,

I have a strange problem. My Qt4 demo program worked 
fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2.
Debugging shows that indeed a div by zero is done within
the Qt4 lib. However with FPC 2.0.0 or using C++ code the library
isn't bothered with the div by zero. When I use FPC 2.0.2 however
it is.

I added some writelns euh printfs in the Qt lib:
 if (p1.x() == p2.x()) printf("Before DIV by Zero: p1.x:%f p2.x:
%f\n",p1.x(),p2.x());
edge.m = (p1.y() - p2.y()) / (p1.x() - p2.x()); // this causes the div by zero
if (p1.x() == p2.x()) printf("After DIV by Zero: p1.x:%f p2.x:
%f\n",p1.x(),p2.x());

with FPC 2.0.2 I get

Before DIV by Zero: p1.x:196.50 p2.x:196.50
An unhandled exception occurred at $405CB772 :
EDivByZero : Division by zero
  $405CB772
etc

with FPC 2.0.0 or the original C++ demo program I get:
Before DIV by Zero: p1.x:196.50 p2.x:196.50
After DIV by Zero: p1.x:196.50 p2.x:196.50
Before DIV by Zero: p1.x:187.50 p2.x:187.50
After DIV by Zero: p1.x:187.50 p2.x:187.50
Before DIV by Zero: p1.x:100.00 p2.x:100.00
After DIV by Zero: p1.x:100.00 p2.x:100.00
and so on, never a crash (but why :-)

Anyone any idea?

I uploaded everything to 
(Qt libs, demo src code)
http://users.pandora.be/Jan.Van.hijfte/qtforfpc/demo_shapedclock_0.6.tar.gz

I compiled Qt 4.1.1 with debug info (hence the size of the tar)
the file I added the printfs was
qt-x11-opensource-src-4.1.1/src/gui/painting/qpaintengine_x11.cpp

compile:
export LD_LIBRARTY_PATH=.
ppc386 -gl  shapedclock.pas
./shapedclock

The program should look like this:
http://users.pandora.be/Jan.Van.hijfte/qtforfpc/shapedclock.png

Here is some gdb output
...
Qt: gdb: -nograb added to command-line options.
 Use the -dograb option to enforce grabbing.
Before DIV by Zero: p1.x:196.50 p2.x:196.50

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1087534720 (LWP 10897)]
0x405cb772 in qt_tesselate_polygon (traps=0xbf812e40, pg=0x8135b50, pgSize=9, 
winding=true)
at painting/qpaintengine_x11.cpp:361
361 edge.m = (p1.y() - p2.y()) / (p1.x() - p2.x()); // line 
derivative
Current language:  auto; currently c++
(gdb) bt
#0  0x405cb772 in qt_tesselate_polygon (traps=0xbf812e40, pg=0x8135b50, 
pgSize=9, winding=true)
at painting/qpaintengine_x11.cpp:361
#1  0x405cca91 in QX11PaintEnginePrivate::fillPolygon_dev (this=0x81351e0, 
polygonPoints=0x81367c8,
pointCount=9, gcMode=QX11PaintEnginePrivate::PenGC, 
mode=QPaintEngine::WindingMode)
at painting/qpaintengine_x11.cpp:1533
#2  0x405cd050 in QX11PaintEnginePrivate::fillPath (this=0x81351e0, 
[EMAIL PROTECTED],
gc_mode=QX11PaintEnginePrivate::PenGC, transform=false) at 
painting/qpaintengine_x11.cpp:1648
#3  0x405cd914 in QX11PaintEngine::drawPath (this=0x81309b8, [EMAIL PROTECTED])
at painting/qpaintengine_x11.cpp:1688
#4  0x405c41db in QX11PaintEngine::drawLines (this=0x81309b8, 
lines=0xbf8132cc, lineCount=1)
at painting/qpaintengine_x11.cpp:907
#5  0x4058285d in QPainter::drawLines (this=0x812e250, lines=0xbf8132cc, 
lineCount=1)
at painting/qpainter.cpp:3243
#6  0x400b7eef in QPainter::drawLine () from ./libqt4intf.so
#7  0x4008f801 in QPainter_drawLine3 () from ./libqt4intf.so
#8  0x080497cf in TCLOCK__PAINT (E=0xbf813848, this=0x812929c) at 
shapedclock.pas:164



kind regards,

Den Jean

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Den Jean]

On Tuesday 07 March 2006 02:45 am, Peter Vreman wrote:
> > Anyone any idea?
>
> In 2.0.0 the fpu exceptions are disabled if linking to C. In 2.0.2 this is
> fixed.

for "man G++ " it is not the default, I could not find Qt makefile
to disable them, so I was a bit perplex. 
(also had integer divisions in mind, quite a difference)

I notice now that even the smallest C++ program has FPE disabled
$ cat test.cpp
#include 
int main() { printf("FPE test:%f\n",142.0/0.0); }
$ ./a.out
FPE test:inf

So I now use fedisableexcept(FE_ALL_EXCEPT); 
in the initialization section of qt4.pas

thx

Den Jean





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Den Jean]

On Wednesday 08 March 2006 10:12 pm, Michalis Kamburelis wrote:
> Maybe you can workaround this with Set8087CW, just like it has to be

see my previous mail
> >So I now use fedisableexcept(FE_ALL_EXCEPT);
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

[Den Jean]

On Wednesday 15 March 2006 01:55 am, Peter Vreman wrote:
> > Hello,
> >
> > Is there a better way to disable fpu exception other then linking to
> > libc and calling fedisableexcept ???
>
> Set8087CW() in system unit
> SetExceptionMask() in unit math
>
It was for MacOsX we needed to get rid of libc,
I guess Set8087CW($133F) is not CPU independant (PowerPC,x86_64),
so I will use
Math.SetExceptionMask([exDenormalized,exInvalidOp,exOverflow,exPrecision,exUnderflow,exZeroDivide]);

I hope MacOsX is happier now (don't have one, so don't know)

kind regards,

Den Jean





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] definition of TRect on Mac OS

[Den Jean]

Hi,

in the Qt4 binding I do a direct copy of qrect into trect,
therefore qrect and trect need to have the same binary layout.

For some reason the definition of trect on Mac Os X is different

qrect.h:
-
#if defined(Q_OS_MAC)
int y1;
int x1;
int y2;
int x2;
#else
int x1;
int y1;
int x2;
int y2;
#endif

I do not have a Mac, so I do not know why. 
I guess for compatible with the OS API.
I only see that in FPC there is not a Mac specific TRect definition (types.pp)

Should there be one?
If not I will solve it in the binding, but perhaps it is 
a good idea to have TRect differently defined on mac
(but breaking binary compatibility ...)
 
please just decide.
 
Den Jean
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] fpc 2.0.4 rc2 and mse

[Den Jean]

Hi,

MSE created some patches for fpc 2.0.4 rc1 
to fix some widestring and db issues.
http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/

I seems they are not applied to rc2.

Can someone with widestring and db knowledge 
of fpc dev take a look at this? 

It would be nice that for mse/fpc we do not
need to apply patches to release 2.0.4 to be able 
to use mse.

thx in advance,

Den Jean


 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc 2.0.4 rc2 and mse

[Den Jean]

>
> The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's.
> What's left is irrelevent, or in the fopen case, an ugly hack that
> shoudn't be there, imho.
>
> So for the db-part, nothing has to change.

thx for checking,
is someone :-) looking to implement/fix blob/text 
in the mysql binding ?
(see mse talk)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Linking to C++

[Den Jean]

On Monday 22 January 2007 20:17, Felipe Monteiro de Carvalho wrote:
> Hello,
>
> Now, I utilized dllview software I created and saw that cpplib exports
> this function: _ZN4User3SumEii
>
IIRC C++ compiler/platform dependant.
So do not use this to be compiler independant
GCC even changed its name mangling in between versions.

> Then, I created a simple pascal software to call that function:
>
> program loadcpp;
>
> {$mode objfpc}{$H+}
> One possible problem is C++ multiple inheritance. I would propose
> that, to start with, just disconsider it.
>
AFAIK the class that inherits from multiple classes, is actually
just several classes with several vtables. To be able to
use it from pascal, the self pointer in
function User_Sum(Self: Pointer; a, b: cint): cint; cdecl; external
should be different depending on which vtable you want to call.

http://www.freepascal.org/wiki/index.php/Qt4_binding#C.2B.2B_Multiple_inheritance

implementation of QWidget_to_QPaintDevice:
QPaintDeviceH QWidget_to_QPaintDevice(QWidgetH handle)
{
return (QPaintDeviceH)(QPaintDevice *)(QWidget *)handle;
}

the typecast (QPaintDevice *) turns the number (QWidget *)handle into another 
number, pointing to another vtable. 

But again this is compiler/version dependant reading the following:
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00620.html


regards,

Den Jean






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel