Re[2]: [fpc-devel] License of RTL

2005-11-10 Thread Pavel V. Ozerski
Hello Marco,

Thursday, November 10, 2005, 10:53:09 AM, you wrote:

 Some files of RTL core are under the full GPL license, not a LGPL. Is it
 a new politics of FPC?

MvdV No. Must have been an oversight/bad copy/paste.
 
MvdV If you have more files, don't hesitate to name them. The syscallh.inc was 
MvdV created by me, so that is certainly a mistake.

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

This list of FPC parts which are published under full GPL is copied
from http://freepascal.ru/forum/index.php?showtopic=445

It is not checked by me, only Russian comments are cut.

FCL:
avl_tree.pp, resolve.pp.

packages\base\mysql - all

RTL\BeOS:
beos.inc, osposix.inc, syscall.inc.

RTL\BSD:
osdef.inc, osmacro.inc; i386: syscall.inc, syscall.h; powerpc: syscall.h; 
x86_64: syscall.h.

RTL\linux:
osdef.inc, osmacro.inc; arm: syscallh.inc; i386: syscallh.inc; powerpc: 
syscallh.inc; sparc: syscallh.inc; x86_64: syscallh.inc.

RTL\objpas\sysutils:
dati.inc, datih.inc, fina.inc, finah.inc, intfh.inc, sysansi.inc, sysansih.inc, 
syspch.inc, syspchh.inc, sysstr.inc, sysstrh.inc, sysuintf.inc, syswide.inc, 
syswideh.inc.

RTL\OS2:
kbdcall.pas, moncall.pas, mouclass.pas, pmgpi.pas, viocall.pas.

RTL\Solaris:
osdef.inc, osmacro.inc.

-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]


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


Re[2]: [fpc-devel] Generics Basics

2005-11-08 Thread Pavel V. Ozerski
Hello all,
I didn't discuss about this idea but now I would say something. Is it
really important, to integrate templates support into compiler? Maybe
an external preprocessing utility should be better? I think, an
integrated complex preprocessor can slow the compiling process very
much even if a source code doesn't contain these syntax extensions.
Very rapid compiling was always a great pascal advantage over c++.
This improvement can kill this advantage.

-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]


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


Re[6]: [fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly

2005-04-28 Thread Pavel V. Ozerski
Hello FPC Team,

Please explain me why my yesterday's work remained be ignored?
Practically, I think, I solved a problem at fixed a bug. Are you
discordant with my way of solution or are waiting for diff?


-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



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


[fpc-devel] is smartlink of Win32 DLLs broken again? And a old FreeBSD port problem additionaly

2005-04-27 Thread Pavel V. Ozerski
Hello all,

1) I tried now to build a dll with {$smartlink on} using 1.9.9 compiler
built at beginning of April. The created DLL did not contain export
names. An analysis of generated asm code pointed that although a
global label at beginning of .rva-containing asm-file has been
correctly created but the PASCALMAIN module did not contain a
reference to this label. At result, all EDATAs sould be eliminated at
linking stage.

2) Because I braced up, to write this letter :), I would also report a
old problem which I got using an old 1.1 FreeBSD port. I needed to
build a shared UDF library for MySQL. While loading created .so file,
I got an error message - something like main entry point not found.
An analysis of asm code demonstated that global main function mas
named not main but had a name combined from a shared module name and
_main, therefore the dynamic linker could not find main entry point.
At that time I solved this problem editing the asm code but this way
seems to be not normal.

Sincerely, Pavel



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


Re[2]: [fpc-devel] Abbrevia and Delphi compatibility

2005-02-16 Thread Pavel V. Ozerski
Hello Jonas,

Wednesday, February 16, 2005, 11:24:00 AM, you wrote:

 1) Properties for Object type.

Should already work with {$mode Delphi} - if this feature is not
broken again now.



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


Re[2]: [fpc-devel] Abbrevia and Delphi compatibility

2005-02-16 Thread Pavel V. Ozerski
Hello Marco,

Wednesday, February 16, 2005, 1:32:58 PM, you wrote:
Currently FPC has special code that forbids property in objects for delphi
mode.

At least Delphi versions from 2 to 7 support propereties for old-style
objects. This feature is used BTW in KOL library. Some years ago I
implemented a patch for FPC 1.1 which resolved this feature for Delphi
compatible mode but suppressed for all others. I hope that this
feature is not removed also now (but I have not latest FPC builds
now).



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


[fpc-devel]smartlink for Win32 dlls fails again

2004-06-29 Thread Pavel V. Ozerski
Hello all,
Today I built last compiler (1.9.5) from sources. Then I tried to compile a
small test win32 dll with -CX -XX and got a binary without export
functions entries. That is interesting that using -a option (using
external assembler) solves this problem.
-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re[2]: [fpc-devel]about the bug 2364

2004-05-14 Thread Pavel V. Ozerski
Hello Peter,

Wednesday, April 28, 2004, 4:02:59 PM, you wrote:

 Hello all,

 I have some ideas about the bug #2363 (Unfixed Error export problem).

 Second way: storing exported items info in PPU.

PV That is possible. It needs a new ppuentry that will contain the following
PV items per export:

PV - procdef reference
PV - exported name
PV - exported index

May be it is possible to avoid adding new entries. I looked a
little... Two kinds of statements can be exported:
procedures/functions and (on some platforms) variables.

tvarsym contains a field varoptions that is a set of tvaroption.
Tvaroption already has vo_is_exported as a possible value.

tprocsym has a field is_global : boolean (unfortunately, only under
{$ifdef GDB}). This field could be easily changed to byte with 3
possible values: 0 - local, 1 - global, 2 - global and exported. That
could cause no changes in binary PPU structure and no changes in other
parts of compiler where this field is already used (only a typecast byte to
boolean is needed). Am I right?


-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel]about the bug 2364

2004-04-28 Thread Pavel V. Ozerski
Hello all,

I have some ideas about the bug #2363 (Unfixed Error export problem).
I see two ways to solve this problem but I'm not sure that I'm able to
realize them.
First way (may be wrong):
generating edata sections (or their analogs for non-Windows platforms)
vor every unit that contains exports clause and making a chain of
these sections using the same way as used to multi-units VMT
generation.
Second way: storing exported items info in PPU.

-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel]Dynamic array problem (FPC 1.9)

2004-01-22 Thread Pavel V. Ozerski
Hello all,
I found a problem with dynamic arrays of shortstrings and of static
arrays. These structures are not supported in Delphi but usually work
normally in FPC (except this case). But if a dynamic array is declared
as typized constant or a variable with initial value then trying to
resize this array (using SetLength) causes the run-time error 216.
Btw, if this dynamic array is declared as a usual variable (without an
initial value), all works OK.
Example:

{$ifdef fpc}
{$mode delphi}
{$endif}
type
 tArr=array[0..4]of char;
var
 a:array of tArr=('0'); //OR a:array of shorstring=('0');
begin
 SetLength(a,2);
 a[1]:='A';
 writeln(a[1]);
end.


-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel]Dynamic array problem (FPC 1.9)

2004-01-22 Thread Pavel V. Ozerski
Hello all,
I found also a problem with TIniFile (1.9, win32). If I try to read an
information from the same .ini file using standard TIniFile methods
from several instances of application at the same time, sometimes I
get an error opening .INI file. I think, INI file creation flags should
be supplemented with sharing-allowed constants or at least in
TIniFile.Create the lines slLines.LoadFromFile(FFileName); and
slLines.SaveToFile(FFileName); should be included into Try..Except
blocks and into Repeat..Until success block.
-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel]I cannot access FPC FTP server

2003-12-24 Thread Pavel V. Ozerski
I try to download last 1.9 sources but cannot access FPC archives via FTP, your
server (ftp://ftp.freepascal.org) seems to be down. What is happened with it?
-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re[2]: [fpc-devel]default calling convention change for i386

2003-12-24 Thread Pavel V. Ozerski
Hello Ingmar,

Wednesday, December 24, 2003, 1:21:32 PM, you wrote:

IT Bad news :(

IT Is this true for all {$mode }'s or only {$mode delphi} ?

Why bad, Try to add {$calling oldfpccall} into your source
-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel]A little fix

2003-09-30 Thread Pavel V. Ozerski
Hello,
After I replaced in t_win32.pas unit a line 698 - from
 exportsSection.concat(Tai_symbol.Create(edatalabel,0));
to
 exportsSection.concat(Tai_symbol.Create_Global(edatalabel,0));
 
the smartlinking of Win32 dlls main modules became possible again.

Sincerely, Pavel



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel