On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel
wrote:
>> I'll write a simple example in the wiki (there's a ToDo for that
>> currently).
> Please do.
Done.
It's a bit more elaborate than just a few lines though.
--
Bart
__
ons 3.1.1 and I immediately
"translated" that to fpc main ;-)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ll be (1,2,3), and changing that will not affect R1.A anymore
Sounds like a nice feature to have (in 3.4).
I'll write some tests to get familiar with this and if I don't forget
I'll write a simple example in the wiki (there's a ToDo for that
currently).
--
Bart
__
the assignment operator, and avoid code like in DoIt().
In such instances it would really be helpfull if you could just
overload the assignment operator like:
operator := (Src: TRec): TRec;
begin
Result := AssignRec(Src);
end;
--
Bart
___
fpc-devel
pc/source/-/issues/40694
There were several commits about Abs w.r.t. this bug lately.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Sun, Dec 17, 2023 at 6:14 PM Marco van de Voort via fpc-devel
wrote:
> Never mind, it is merged. The road blocks turned out to be in the
> dotted RTL related revisions (since it is a pchar based routine), so in
> the end I manually merged.
Thank you very much.
ail
Expected: one[CR]two[CR]three
Got : one[LF]two[LF]three
The code for main outputs:
LF: OK: one[LF]two[LF]three
CR: OK: one[CR]two[CR]three
CRLF: OK: one[CR][LF]two[CR][LF]three
LF to CR: OK: one[CR]two[CR]three
LF->CR->CRLF: OK: one[CR][LF]two[CR][LF]three
CRLF->LF->CR:
On Mon, Oct 2, 2023 at 9:01 AM Michael Van Canneyt via fpc-devel
wrote:
> I did so, I left a small request.
I attached a small test program to the bugreport (with a question).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
/freepascal.org/fpc/source/-/issues/40261#note_1406426712
fixes this at the expense of calling BeginUpdate/EndUpdate (and for
that use a try..finally construct).
I kindly ask for this patch to be reviewed by one of the devels.
--
Bart
___
fpc-devel
w, it's easy...)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Wed, Mar 29, 2023 at 11:43 PM Bart wrote:
> I'll report it in the bugtracker.
https://gitlab.com/freepascal.org/fpc/source/-/issues/40225
I condensed the program even further.
Just concatenating 2 strings in Foo and assigning them to S will be
enough to trigger the memory leak.
--
B
r: String;
begin
Result := 'X';
Result := Result + 'Y';
end;
If the initial assigment to Result is an empty string, then no leak occurs.
I'll report it in the bugtracker.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.
===
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas -gl -gh
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
test.pas(11,3) Note: Local variable "S" is assigned but
ago (it was about
optimization levels in gcc), which explained all this, but I'm unable
to find that again and unanble to reproduce what was being said there.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/ma
default HKEY_CURRENT_USER;
>
> Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect.
Reported: https://gitlab.com/freepascal.org/fpc/source/-/issues/40148
(with simplified example).
--
Bart
___
fpc-devel maillist - fpc-d
: array[TRegKey] of HKEY = (HKEY_CLASSES_ROOT,
> HKEY_CURRENT_USER, ...);
Yep, thought of that as too.
Perhaps the best options.
Thanks.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e value in
lfm and reading it back using different bitness versions of Lazarus?
Should I even publish such a property?
(I don't think Lazarus has a property editor for HKEY...)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://li
On Sun, Feb 12, 2023 at 10:49 PM Bart wrote:
> For 32-bit builds this results in the final HKEY value being identical
> to the original literal value, but for 64-bit builds, because of the
> intermediate signed LONG cast which is then cast to the larger
> unsigned ULONG_PTR type,
oesn't even know about QWord (or 64-bit for that matter),
so I cannot test this.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect.
If the reported range is incorrect, then the error is incorrect: the
value is perfectly inside the range of a QWord...
So, the question remains: is the compilation error a bug?
--
Bart
__
ecause QWord(some not so big negative number) = some large positive number.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
d fpc main 3.3.1-2495-g6453af40d8
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
reference
> in all cases. The
> latter is therefore typically used for interfacing with external code or when
> writing assembler
> routines."
>
> In your case, constref is the right choice, although const would be fine also
> (as your
> datastructure is larger than a
ure itself.
Hence my question: is it OK to use constref for a parameter (and is it
guaranteed to work by design this way) if I need to pas a parameter by
reference and the function/procedure shall not modify that parameter?
(B.t.w.: Where can I find the official documentation on constref?)
On Fri, Jan 13, 2023 at 1:16 PM Michael Van Canneyt
wrote:
> > Should I report this as a bug?
>
> Yes.
Done.
https://gitlab.com/freepascal.org/fpc/source/-/issues/40108
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepasc
e hint: Unit "version" not used in test
This is obviously not true, without the unit version, the program won't compile.
Should I report this as a bug?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepa
egin/end" error with the caret
> pointing to the 2nd begin...
>
> --
That's a copy/paste error.by me.
The original code had about 10 more function calls and then a closing
end for the "with WideStringManager do begin "
--
Bart
__
rted as issue #40106
On Thu, Jan 12, 2023 at 9:39 PM Sven Barth wrote:
>
> Am 11.01.2023 um 23:58 schrieb Bart via fpc-devel:
> > Given the following program (an excerpt form a test program for a
> > bugreport about the fpwidestring unit):
> >
> > ===
(PChar(ASource), CP_UTF8, UDest,
Length(ASource)); //<< test.lpr(24,53) Error: Can't take the address
of constant expressions (caret behind UDest)
end.
C:\Users\Bart\LazarusProjecten\bugs\Console\fpwidestring>fpc test.lpr
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright
wrong (it
should use the ValueType parameter and then figure out if it is NaN in
some way).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-vd gives no additional information AFAICS:
Debug: Resource information read
Debug: Trying to open file main.lfm...
Debug: Chosen reader: DFM resource reader
Debug: Reading resource information...
Error: Invalid property value (at 41,17, stream offset 031A)
C:\Users\Bart\LazarusProjecten\bugs\spi
t faile on type Currency in
Win64 with fpc 3.2.2.
See https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39490
Also, overriding is needed for anything with a range > Single, so you
only spare yourself the implementation in TSpinEditEx, where you could
do a simple A=B com
Int64 above).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Sun, Sep 18, 2022 at 2:29 PM Bart wrote:
> > Just enable fpc_math_samevalue_bug
> >
> > {$if FPC_FullVersion=30202}{$ifdef Win64}
> >{$define fpc_math_samevalue_bug}
> > {$endif}{$endif}
OMG.
I only found out right now that this define is already there.
Oh,
scal.org/ExCtrls).
This may be the cleaner solution though.
)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Sun, Sep 18, 2022 at 1:17 PM Maxim Ganetsky via fpc-devel
wrote:
> As far as I see from CI build log, FPC 3.2.0 is the culprit. FPC 3.2.2
> compiles your code fine both on Linux and Windows.
Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1.
--
and thus
also crashed in the IDE.
So, I tried the same solution there: typecast DefMaxValue as
T(DefMaxValue) in the call to SameValue and then it turned out this
wouldn't compile on MacOS and Linux 64 bit.
--
Bart
___
fpc-devel maillist -
anybody have an opinion about this?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
go ahead.
Done.
https://gitlab.com/freepascal.org/fpc/source/-/issues/39776
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
to have them on my
regular computer (of which I only have one)
Please post the output of a modern Delhi with the code above.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ot;Illegal family", as D7 does?
I would leave it as it is, since "illegal family" is a legal name for
a family to register...
@Marco: I first need to have the patches in #39774 and #39773 applied
before embarking on this.
--
Bart
___
On Wed, Jun 8, 2022 at 3:55 PM Stefan Glienke via fpc-devel
wrote:
> Actually the behavior in Delphi depends on the $R switch.
D7:
{$R+}
ConvTypeToDescription(-1)=[$]
{$R-}
ConvTypeToDescription(-1)=[$]
Bart
--
Bart
___
fpc-de
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
Actually it is documented to be of type Word:
https://docwiki.embarcadero.com/Libraries/Sydney/en/System.ConvUtils.TConvType.
I guess nobody needs mor
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
>
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
And as a consequence compilation in Delphi fails if a negative value
is supplied to a function that takes a TConvType as a parameter, but
also
And another observation: on Delphi 7 TConvType seems to be unsiged (in
fpc it's signed).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
the function RegisterConversionFamily() should
never return CIllegalConvFamily .
I.o.w. the internal array should not start at 0 (or the 0-index should
be filled with info that represents an illegal family).
So, any fix would break Delphi compatibility?
Q1: Can somebody test with a modern Delphi?
Q2: Any
://en.wikipedia.org/wiki/Conversion_of_units#Temperature
There is adding/subtracting involved in the calculations, not jus a
single conversion factor.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
find info in Delphi's DocWiki), but if it is not:
Is this by design or is it a bug?
Bart
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
eally welcome this "combined" installer.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
to Q1 is "Yes" and somebody can explain how to do Q2 (or
preferrably implement that part), I can work in avoiding the range
check errors (that should be rather easy then).
(Mind you, I can only fix and test for/on i386 and X86_86, so I won
e results.
Thanks for explaining.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Thu, Dec 30, 2021 at 1:05 PM Jonas Maebe via fpc-devel
wrote:
> > Nor why it only triggers with Byte + Byte + Unsigned, and not with
>
> In you original mail, you said it triggered for Byte + Byte + Signed.
Yes, of course, the original mail is correct.
> It doesn't trigger for Byte +
['htmlspecialchars']
from the changelog
(https://download.simplemachines.org/index.php?thanks;filename=smf_2-0-19_changelog.txt)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Fri, Dec 31, 2021 at 8:49 AM Marc Weustink via fpc-devel
wrote:
Somebody on the forum said it happened before the server upgrade.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman
single quote inside a [code=pascal] block into a
HTML-entity:
It does that for all highlighters (including [code=Text]), but not for
plain [code][/code] blocks.
See: https://forum.lazarus.freepascal.org/index.php/topic,57672.0.html
--
Bart
___
fpc-de
signed.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Jun 28, 2021 at 8:33 PM Bart wrote:
> Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with
> value < 0) will always give a range check error on X86_64 platform (if
> range checking is enabled).
Bump...
--
Bart
_
On Tue, Dec 28, 2021 at 9:41 AM Marc Weustink via fpc-devel
wrote:
>
> To be continued...
Wow..
Hats off to you.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
foo(y); //line 10
end;
begin
end.
test.pas(10,8) Error: Can't assign values to const variable
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
er the value of that
parameter, whilst that function is still running.
Any side effects of circumventing the compilers efforst to enforce
this are at your own risks.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi
On Tue, Nov 30, 2021 at 7:53 PM Bart wrote:
> I think I also discussed this on the
> fpc-devel list, musty have been august this year, since around that
> time I created my "unlinkcommondll" utility as a workaround.
Indeed:
Building trunk of today fails on Windows: Error: Inv
ll (so that you can restore it in the unlikely event
that your windows stops functioning).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi,
Can somebody move
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39381 to
fpc please?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Sat, Sep 4, 2021 at 3:26 AM Gennady Agranov via fpc-devel
wrote:
IIRC then there were som bugs regarding optimization in win64.
You can try to compile with optimizations disabled: -O- (or use the
Lazarus dialog to do so).
--
Bart
___
fpc-devel
;
/devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./fpmake.exe; make
fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
operable program or batch file.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.
2-bit DLL in
> the System32 directory of a x86_64 system.
Even if the dll does not match the description/specs in the source code?
(Just curious)
And, being curious: any idea why make clean failed when %PATH% was set
to just C:\fpc\3.2.2\bin\i386-win3
On Mon, Aug 23, 2021 at 8:04 PM Bart wrote:
> And, of course, the guide on how to remove this utility
> (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
> do not apply.
> No XtuService in "Apps and Features&qu
to build fpc, it WILL find the dll in
c:\windows\system32.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Aug 23, 2021 at 7:45 PM Bart wrote:
> Productname: Intel(R) Extreme Tuning Utility
And, of course, the guide on how to remove this utility
(https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
do not apply.
No XtuServ
ed in some Windows update.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote:
> I tried to build with only the path to the starting compiler in %PATH%:
>
> PATH /devel/fpc/3.2.2/bin/i386-Win32
> make clean
> make all OPT=...
>
> That failed on make clean:
That error goes away if I add C:\Windows to the p
On Mon, Aug 23, 2021 at 3:19 PM Bart wrote:
> Should I start the build process with a %PATH% that does NOT have
> C:\Windows\system32 in it?
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That
EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED
start address 0x
It says it's a 64-bit dll?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ystem2 or
syswow64, Windows just makes fpc believe it is in system32 anyway, AND
fpc decides this is the wrong common.dll and aborts.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
fail, since the libraries are just not on my system)
Should I start the build process with a %PATH% that does NOT have
C:\Windows\system32 in it?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
m32 is wrong.
Does that imply that, when I have a 32-bit program do a FindFirst for
common.dll in the system32 folder, Windows just tells the program that
the file is there?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.fr
one is 32 or 64 bit.
(And even that one is 32-bit and the header is wrong, the errormessage
would still be wrong, since it explicitely mentions
C:\Windows\system32).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
searches (and
does not find: the errormessage is wrong w.r.t. that) and fails for
32-bit, not where it finds and succeeds for 64-bit and arm-wince.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
or that)...
Also, the message is wrong.
It says the file in that location has the wrong header, but the file
does not even exist in that location.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
le lib?
This is so frustrating.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ed if anybody can explain why this
(building trunk) worked before, but does not anymore.
Also can anybody explain why all the other {$linklib xxx} lines do NOT
cause compilation and linking to fail??
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Sun, Aug 22, 2021 at 10:20 AM Bart wrote:
> So, this baffles me.
As does this:
C:\devel\fpc\trunk\packages\oracle>type README.txt
These units provides interface to Oracle Call Interface.
For the older 'oraoci' unit to compile you need oracle
server installed, these units was
{$linklib nlsrtl3}
{$ifndef BSD}
{$linklib dl}
{$ENDIF}
{$linklib c}
Why does it not complain about either of these?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
only change I made to my
computer is installing a git client (commandline version).
My windows is up to date.
So, this baffles me.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Windows\SysWOW64
24-02-2021 10:18 425.024 Common.dll
Since when is this dll needed to build fpc?
Can I circumvent this requirement?
Am I required to install some additional software?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
2 and fpc trunk)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi Marco,
You made a typo in the comment:
// extended colosr (from lazarus Graphics)
Should be
// extended colors (from lazarus Graphics)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman
copyright, but that
was flushed away by all errors).
Is it at all possible to have the installer just update the old
reference in %path% to the new one?
e.g.
c:\windows\;c:\path\to\old\fpc;c:\delphi\bin
becomes
c:\windows\;c:\path\to\new\fpc;c:\delphi\bin
and not
c:\windows\;c:\delphi\bin;c:\path\to\new\fpc
/3.2.2-rc1/i386-win32/ ?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Wed, Feb 24, 2021 at 1:42 PM J. Gareth Moreton via fpc-devel
wrote:
> The messages are marked as private.
They weren't in the past though.
The good news is that I don't have to get new glasses.
--
Bart
___
fpc-devel maillist - fpc-de
On Wed, Feb 24, 2021 at 10:06 AM Bart wrote:
> I have downloaded that file (some time ago)
The download links seems to have gone from the bugreport?
(Or maybe I need new glasses)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.
ion of ifdefs (so I gave up trying to simplifyt the
problem).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e.
https://bugs.freepascal.org/view.php?id=38342
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
uld have helped if the error message was a little less cryptic,
and/or if it pointed to the line that caused the error in the first
place.
Of course I have no idea wether or not this error message only applies
to the situation I encountered...
Bart
--
Bart
__
ementation section are simply not available then thus its
> forbidden right away. This is Delphi compatible.
Thanks for explaining this.
The errormessage is probably technically correct, but for me it might
be a little more informative (so that I can tell what I
Hi,
While trying to solve https://bugs.freepascal.org/view.php?id=38306 I
got this error I have never seen before.
_gdeque.pp(249,4) Error: Global Generic template references static symtable
_gdeque.pp(302) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Line
I filed a bugreport: https://bugs.freepascal.org/view.php?id=38309
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Jan 4, 2021 at 11:00 PM Bart wrote:
> So, most likely this has nothing to do with generics?
> I'm using r47193 of fpc trunk
Try to compile attached program for Win64-bit with either 3.2.0 or trunk:
Free Pascal Compiler version 3.2.0 [2020/06/04] for x86_64
Copyright (c) 199
On Mon, Jan 4, 2021 at 5:13 PM Bart wrote:
>
> > What is strange to me is that the compilation issue does not happen with
> > the LazControls package alone, but only when ExCtrls package is added.
> > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Win
n Windows)
Currency on 64-bit might be the culprit. IIRC it had another datatype
then on other platforms.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
1 - 100 of 310 matches
Mail list logo
