On Sun, Jul 6, 2025 at 1:57 PM Martin Frb via fpc-devel
wrote:
> program Project1;
> {$mode objfpc}
> type TFoo = class end;
> TFooClass = class of TFoo;
> var f: TFoo;
> fc: TFooClass;
> begin
>fc := TFoo;
>f := fc.Create;
>f := TFooClass.Create; // works
> end.
Delph
On Mon, Apr 7, 2025 at 1:12 PM Marco van de Voort via fpc-devel
wrote:
> IMHO it is a feature better forgotten.
+1, it's an abomination IMHO ;-)
Out of curiosity: could the zerobased-ness of the string be stored in
the string's "header"?
--
Bart
___
On Tue, Apr 8, 2025 at 12:09 AM Sven Barth via fpc-devel
wrote:
>> > Please report a bug.
>> Done: https://gitlab.com/freepascal.org/fpc/source/-/issues/41228
>
>
> Turns out I had been too eager to request a bug report. But thank you
> nevertheless. 😅
Well, similar off-by-one inconsistencies
On Mon, Apr 7, 2025 at 8:17 AM Sven Barth via fpc-devel
wrote:
> Please report a bug.
Done: https://gitlab.com/freepascal.org/fpc/source/-/issues/41228
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi
Hi,
Is this a known issue?
===
program z;
{$longstrings on}
{$zerobasedstrings on}
var
S, T: string;
begin
S := 'ABC';
write('S[0]= "',S[0],'"');
if (S[0] <> 'A') then writeln(', FAIL: expected: A') else writeln(' [Ok]');
write('S[1]= "',S[1],'"');
if (S[1] <> 'B') th
On Tue, Feb 25, 2025 at 10:35 PM Tomas Hajny via fpc-devel
wrote:
> No, it's because you used a different compilation mode _and_ FPC treats
> @ differently depending on the compilation mode. If you change "{$mode
> fpc}" to "{$mode delphi}" I guess that Delphi 7 might give you the
> same
> res
Hi,
I possibly did not search hard enough, but did not find what the
"rules" are regarding overload selection (is that the correct term?).
Consider this simple example:
===
program test;
{$ifdef fpc}
{$mode fpc}
{$endif fpc}
{$apptype console}
{$ifndef fpc}
type
TProcedure = procedure;
{$endif
Hi,
I have a unit with these procedure definitions:
type
TCompareItemsFunc = function (p1, p2: Pointer): Integer; //should
return -1, 0, or +1 only
TExchangeItemsProc = procedure(p1, p2: Pointer);
procedure ArraySort(Left, Right: Pointer; ElemSize: SizeInt;
CompareItems: TCompareItems
Hi,
Reporter Jorg3000 posted a snippet of source code from Delphi:
https://gitlab.com/freepascal.org/fpc/source/-/issues/41150#note_2347492532
Can somebody please remove this code snippet?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.
On Sun, Feb 9, 2025 at 9:30 PM Michael Van Canneyt via fpc-devel
wrote:
> The primary purpose to have it in FPC is Delphi compatibility,
> and in particular to be able to compile FMX applications (which is now
> possible).
>
> We can try to enhance it with things needed by Lazarus,
That's nice
Hi,
The Delphi compatible unit System.UITypes is getting out of sync with Lazarus.
The reason for this is twofold:
1. the faster release cycle of Lazarus
2. the fact that Lazarus supports more widgetsets, for which we also
need enumerations, and Delphi does not have these.
This can lead to errors
On Fri, Feb 7, 2025 at 5:39 PM Bart wrote:
> D7 refuses to compile this code (even with "overload"), but D7 is a
> little bit old...
Well, Delphi is a bit picky about the order: it must be "overload;
virual;" (I had "virual; overload;")
So, with that fixed, D7 compiles the code as well.
--
Ba
On Fri, Feb 7, 2025 at 2:40 PM Maxim Ganetsky via fpc-devel
wrote:
It compiles if you declare the methods in TBase as "overload".
D7 refuses to compile this code (even with "overload"), but D7 is a
little bit old...
--
Bart
___
fpc-devel maillist -
Hi,
We have:
Procedure TStrings.Slice(fromIndex: integer; aList : TStrings);
(and a similar function)
I can figure scenario's where also an EndIndex would come in handy:
Procedure TStrings.Slice(fromIndex, EndIndex integer; aList : TStrings);
Would such be acceptable to add?
--
Bart
__
On Thu, Jun 27, 2024 at 4:51 PM Michael Van Canneyt via fpc-devel
wrote:
> As a consequence, things may go unnoticed, this is not a reflection
> on the seriousness of an issue or quality of the patch.
>
> Feel free to contact us here or by other means if you feel that a bugreport
> is ignored.
On Fri, Jun 21, 2024 at 8:16 PM Marco van de Voort via fpc-devel
wrote:
> Probably terminate with a heap out of memory error.
OK, that's better than silently failing!
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.fr
Hi,
Possibly not a real-world problem, but some pet-project of mine has to
deal with it (at least in theory).
What happens if you try to concatenate 2 huge ansistrings, such that
Length(String 1) + Length(String 2) > High(SizeInt)?
All this assuming you have memory enough to perform such an opera
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
___
fpc-devel ma
On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel
wrote:
> Management operators are already part of 3.2.x (
> https://wiki.freepascal.org/FPC_New_Features_3.2.0#Management_operators_for_record_types
> ). Or did I misunderstand your remark? 🤔
I misread the wiki page (it mentions 3.1.1 a
On Thu, Apr 25, 2024 at 11:18 AM Sven Barth via fpc-devel
wrote:
> If there exists a built-in operator then overloading that operator is
> forbidden to avoid confusion when what operator might be used (operators can
> after all be declared *anywhere* and thus they might sometimes be used and
>
Hi,
Overloading the := (assignment) operator for equal types is forbidden.
Out of curiosity I would like to know why that is?
When you have e.g. a record definition containing a dynamic array, not
being able to overload the assignment operator is just a PITA.
OK, once you know why the assignment
On Thu, Apr 4, 2024 at 9:49 PM Martin Frb via fpc-devel
wrote:
> The below writes: -9223372036854775808
>
> Shouldn't absolute return a positive number?
>
> program Project1;
> begin
>writeln( abs(low(int64)) );
> end.
See https://gitlab.com/freepascal.org/fpc/source/-/issues/40694
There we
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.
--
Bart
Hi,
Just noticed that AdjustLineBreaks is broken if the Style parameter is
set to tlbsCR. (Tested with 3.2.2).
In fpc main this is fixed, in fixes_3_2 this still seems broken.
The fix in main was committed in 1c4151d8 (1 merge reques t!396 Fix,
shorten*, and speed up AdjustLineBreaks.( MR by Rika
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
https:/
Hi,
Issue 40261 is about TStrings.AddObject issueing 2 consecutive
OnChange events (and in the first one the to be added object is
unassigned when accessing Objects[] property) when using InsertObject,
AddObject and AddPair.
This is Delphi incompatible.
The patch attached to
https://gitlab.com/fr
On Thu, Jul 20, 2023 at 7:59 AM Sven Barth via fpc-devel
wrote:
> It is indeed by design that not every integer type is a suitable index
> variable for a for-loop. In this case that a 64-bit variable can't be used on
> a platform with less than 64-bit width. The same is probably also true for
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.
--
Bart
___
On Wed, Mar 29, 2023 at 11:44 AM Ondrej Pokorny via fpc-devel
wrote:
>
> FYI: Delphi doesn't create a memory leak.
>
The memory leak seems to be related to string concatenation in the
getter for the Text property.
A getter like this is enough to get the leak:
function TBar.GetTextStr: String;
beg
Hi,
The following program gives a memory leak:
===
program test;
{$mode objfpc}
{$h+}
uses
Classes;
var
SL: TStringList;
procedure Foo;
const
S: String = '';
begin
S := SL.Text; // << this is line 13
end;
begin
SL := TStringList.Create;
SL.Add('1');
Foo;
SL.Free;
end.
===
C:\Use
On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel
wrote:
> So for a while now fpc 3.3.1 receives new optimizations => which is
> great / big fan of it.
>
> And hence I thought, lets see how much of an impact they have. And in my
> test, they had none :(
Optimizations beyond O2 (or even O1
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel
wrote:
> Error "Range check error while evaluating constants (18446744071562067969
> must be between -2147483648 and 4294967295)"
> is wrong here:
>
> property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER;
>
> S
On Mon, Feb 13, 2023 at 8:20 AM Ondrej Pokorny via fpc-devel
wrote:
> I wouldn't publish the HKEY property but create an own enumeration for it:
>
> TRegKey = (rgClassesRoot, rgCurrentUser, )
>
...
>
> Then make a simple transformation to HKEY:
>
> RegKeyToHKey: array[TRegKey] of HKEY = (HKEY
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel
wrote:
> Afaik it's because "default" doesn't support qword values, iirc because
> of (at least old) Delphi compatibility.
OK, I removed the "default".
Theoretically would that lead to problems when storing the value in
lfm and reading
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, the original val
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel
wrote:
> Afaik it's because "default" doesn't support qword values, iirc because
> of (at least old) Delphi compatibility.
Would the original code example compile in a modern 64-bit Delphi
(targeting Win64)?
My old D7 doesn't even know a
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel
wrote:
> Declarations like this have been made on purpose:
> HKEY_CURRENT_USER = HKEY(longint($8001));
>
> On Win64 HKEY_CURRENT_USER must be $8001, but on Win32 it must
> remain $8001.
>
> See commit 2012220aec6749
On Sun, Feb 12, 2023 at 6:26 PM J. Gareth Moreton via fpc-devel
wrote:
>
> If HKey is unsigned, then yes, the definition should be
> HKEY(DWORD($8001)). I do wonder why Win64 produces that particular
> error though because the final destination is an unsigned 64-bit integer.
Because QWord(so
Hi,
This code compiles happily for Win32, but refuses to compile for Win64:
program test;
{$mode objfpc}
{$h+}
uses
Registry;
type
TA = class
private
FRootKey: HKey;
public
//Win64/X86_64 Error: Range check error while evaluating constants
(18446744071562067969 must be betwe
On Wed, Feb 1, 2023 at 11:56 AM Adriaan van Os via fpc-devel
wrote:
> That is wrong. It should read
>
> "A const parameter is be passed by reference or (for small-sized parameters)
> by value, whatever is
> most efficient. A constref parameter is guaranteed to be passed by reference
> in all ca
Hi,
I have a function that has a parameter to a datastructure with some
arrays with records is it.
This function needs to return a pointer to a specific record inside
that structure.
The function is not supposed to alter the contents of this datastructure.
So, I need to pass this structure by refe
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.freepascal.org
https://lists.f
Consider the follwoing program:
===
program test;
uses
Version;
begin
{$if TheVersion >= 1}
writeln('Version 1 or higher');
{$else}
writeln('Version < 1');
{$endif}
end.
===
unit version;
interface
const
TheVersion = 1;
implementation
end.
===
Compile with -vh
You get the hint:
On Fri, Jan 13, 2023 at 11:13 AM wkitty42--- via fpc-devel
wrote:
>
> > First of all, adding a 'end;" for the "with" compiles under Linux.
> > That's because widestring=unicodestring on Linux.
>
> i'm a little surprised there is no "mismatched begin/end" error with the caret
> pointing to the 2nd
Reported 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):
> >
> >
Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):
===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}
uses
FpWideString;
var
WSource: WideString = 'source';
USource: UnicodeString = 'source';
WDest: WideString = '' ;
UDest: Un
Hi,
In #989895c8 I introduced a check for NaN in the IntFloatToTextFmt function.
This check is performed on the untyped parameter Value, typecasted to
Extended (or possibly Currency) (variable E).
As it turns out this only evaluated to True if Value actually is an Extended.
If you would call the f
Hi,
When in Lazarus I set a property of type Double to -Inf or +Inf, I get
a compilation error:
Error: Invalid property value (at 41,17, stream offset 031A)
sp.lpr(20,1) Error: Error while compiling resources -> Compile with
-vd for more details. Check for duplicates.
(Compiling with -vd giv
On Sun, Sep 18, 2022 at 3:27 PM Martin Frb via fpc-devel
wrote:
> And if the base class has
> function SameValue(AValue1, AValue2: T): Boolean; virtual; // but
> not abstract
>
> Which implements the old call, without typecast?
I think Werner already tried that and it faile on type Currency
On Sun, Sep 18, 2022 at 3:09 PM Werner Pamler via fpc-devel
wrote:
> > Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1.
> Sorry if I was not precise here: I only tested with fpc 3.2.0.
I misread, my mistake.
Q1: these ifdef-ed code: does it have to be in the protected
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, and on Linux my fpc was still
On Sun, Sep 18, 2022 at 1:34 PM Martin Frb via fpc-devel
wrote:
> Just enable fpc_math_samevalue_bug
>
> {$if FPC_FullVersion=30202}{$ifdef Win64}
>{$define fpc_math_samevalue_bug}
> {$endif}{$endif}
This suggest that the bug is in Windows 3.2.2
> Make it
> {$if FPC_FullVersion<=30202}
>
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.
--
Bart
Hi,
The following program will compile for Windows 32 and 64 bit.
It fails to compile for Linix 64 bit (and if I understand correctly,
also for MacOS 64 bit).
=== begin code ===
program test;
{$mode objfpc}
{$H+}
{$ifdef FPC_HAS_TYPE_EXTENDED}
function SameValue(const A, B: Extended): Boolean;i
Hi,
The RegisterConversionType() function has an overload with two
paramters of type TConversionProc.
It is used for conversions that have different offsets on their
respective scales (like temperature).
If used like:
=== code ===
tuFahrenheit :=
RegisterConversionType(cbTemperature,txttuFahrenhe
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel
wrote:
> I doubt that there are mission critical convutils programs out there,
> given the fact that it took 10+ years to find out the temperature
> conversion didn't work :-)
>
> Usage is low, risk is small, I say, go ahead.
Done.
On Thu, Jun 9, 2022 at 1:53 PM Stefan Glienke via fpc-devel
wrote:
> I usually don't take 20 year old compilers as reference
That's all that I have.
I do Lazarus/Fpc as a hobby and am unwilling to spend lost of money on Delphi.
Also the latest "free" versions are way to bloated to have them on my
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel
wrote:
> I doubt that there are mission critical convutils programs out there,
> given the fact that it took 10+ years to find out the temperature
> conversion didn't work :-)
I agree.
I only stubled upon this unit because I have u
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-devel ma
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 more than 65
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 code like this
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
Hi,
I've been trying to improve the ConvUtils unit.
Now I've ran into a problem.
ConvTypeToFamily returns CIllegalConvFamily (=0) if AType is not registered.
This however is a problem. If AType is a type registered in the first
registered family, ConvTypeToFamily will also return 0.
This means th
Fpc 3.3.1
===
D := ConvUtils.Convert(100.0, tuCelsius, tuKelvin);
write('100.0 Celsius --> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuCelsius);
writeln(D:12:4, ' Celsius');
D := ConvUtils.Convert(100.0, tuFahrenheit, tuKelvin);
write('100.0 Fahrenheit-->
Hi,
User Nimral in the wiki noted this:
If you specify ifoWriteStringBoolean in Options for TIniFile _and_ you
forget to assign values to BoolTrueStrings/BoolFalseStrings, then
writing and reading boolean values is not symmetrical.
Writing a boolean will write either 'true' or 'false', but reading
On Wed, Jan 12, 2022 at 1:38 PM Martin Frb via fpc-devel
wrote:
> As I said, I do not know, what is currently provided by the Fpc
> "combined 32-/64-bit download".
> No Idea, if any of the fpc/ppc executable in this download are already
> 64-bit.
It provides 32-bit fpc (so it builds for 32-bit
Hi,
There's been a hot debate in the bugtracker about fixing Val() for
signed variables.
There's a patch (in fact there are several), and an attempt to speed
Val() up significantly by having helper functions for each type of
input.
It looks like this is going to be fixed soon (and hopefully be merg
On Sat, Jan 1, 2022 at 1:21 PM Jonas Maebe via fpc-devel
wrote:
> > And the consequence is that even if we eventually have native 128-bit
> > integer support, the problem will persist but now for Int128?
>
> Yes, unless we would only support/use it for intermediate results.
Thanks for explaining
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 + *Signed
From the forum discussion:
https://www.simplemachines.org/community/index.php?topic=580033.0
Could be related to the following fix
September 2021
---
! Fix handling 2x-encoded entities in $ent_check/$smcFunc['htmlspecialc
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/listinf
Hi Marc,
> It took a bit longer than expected, but I'm happy to inform you that the
> Lazarus services are back online.
> For those interested in why it took longer, I'll explain at the end of
> the message.
Are you aware that there is a problem with the forum?
It will change any single quote ins
On Tue, Dec 28, 2021 at 9:38 PM Jonas Maebe via fpc-devel
wrote:
>
> https://gitlab.com/freepascal.org/fpc/source/-/issues/37875
OK, but from reading that it is still unclear to me wether this is a bug or not.
Nor why it only triggers with Byte + Byte + Unsigned, and not with
Byte + Unsigned.
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
___
fpc-devel maill
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
On Fri, Dec 24, 2021 at 12:00 PM Adriaan van Os via fpc-devel
wrote:
> Neither would the compiler allow (I hope) the const parameter to be passed as
> a var parameter.
It does not:
{$mode objfpc}
{$h+}
procedure foo(var x: integer);
begin
end;
procedure bar(const y: integer);
begin
foo(y);
On Mon, Dec 20, 2021 at 12:07 PM Martin Frb via fpc-devel
wrote:
> https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4
> > Specifying a parameter as Constant is giving the compiler a hint that
> the contents of the parameter will not be changed by the called routine.
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: Invalid DLL
C:\WINDOWS\
On Tue, Nov 30, 2021 at 7:42 PM J. Gareth Moreton via fpc-devel
wrote:
>
> Yeah, that's the exact same file that I have problems with.
>
That file links to many more libs trhat I don't have, which does not
create a problem when building (it would of course not run).
It's just that you happen to h
On Tue, Nov 30, 2021 at 8:33 AM J. Gareth Moreton via fpc-devel
wrote:
> For a while now I've had problems building the i386-win32 compiler under
> my 64-bit Windows system because one of the packages fails to build -
> this is because it thinks a statically-imported DLL (done through
> $linklib)
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 mail
On Wed, Aug 25, 2021 at 11:11 AM Tomas Hajny via fpc-devel
wrote:
>
> > And, being curious: any idea why make clean failed when %PATH% was set
> > to just C:\fpc\3.2.2\bin\i386-win32 ?
>
> No idea - I just tested on a MS Win machine I have access to and 'make
> clean all' succeeded with PATH conta
On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel
wrote:
> Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there
> would be no problem. However a 64-bit DLL in the SysWOW64 directory
> (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in
>
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", no XtuService.exe.
On Mon, Aug 23, 2021 at 8:15 PM Yuriy Sydorov via fpc-devel
wrote:
> On 64bit Windows system32 contains only 64 bit system files. syswow64
> contains only 32 bit files and is seen as system32 for 32 bit apps. For
> some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need
> to m
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 XtuService in
Looking with Windows Explorer at the Common.dll in question:
Productname: Intel(R) Extreme Tuning Utility
File version 7.3.0.33
Product version 7.3.0.33
Modified: 24-02-2021 (that's dd-mm-)
In the tab "Previos Version" it says: no previous version.
This must have been installed in some Windo
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 path.
However, then I get
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 failed on
On Mon, Aug 23, 2021 at 2:45 PM Michael Van Canneyt via fpc-devel
wrote:
> Use objdump, provided with FPC:
Thanks!
C:\devel\fpc\trunk>objdump -f \windows\SysWOW64\Common.dll
\windows\SysWOW64\Common.dll: file format pei-x86-64
architecture: i386:x86-64, flags 0x012f:
HAS_RELOC, EXEC_P,
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
wrote:
> Just move common.dll from SysWOW64 to system32. The file is placed wrongly
> by some installer.
If I understand Tomas correctly then that would not make any
difference: wether or not that specific common.dll is in system2 or
sy
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel
wrote:
> The problem is that MS Windows employs a special trickery by which the
> path to c:\windows\system32 (almost surely in your PATH) translates to
> c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that
> directory _
On Mon, Aug 23, 2021 at 3:01 PM Tomas Hajny via fpc-devel
wrote:
> The compiler finds the DLL by looking to C:\Windows\system32. As
> mentioned in another e-mail, the fact that this request is redirected to
> C:\Windows\SysWOW64 instead by the underlying operating system is a MS
> Windows tricker
On Mon, Aug 23, 2021 at 2:28 PM Tomas Hajny via fpc-devel
wrote:
> Does it exist in C:\Windows\SysWOW64\ on your machine?
Yes, there is a common.dll there.
I think that syswow64 is not in my %PATH%, but currently I'm at work
and cannot check.
I also do not know how to examine wether this one is
On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel
wrote:
> > Does anybody have a common.dll in \windows\system32 at all?
>
> I don't have it, neither in system32 nor in SysWOW64.
OK.
> Just pulled the current revision of fpc-trunk, and did not observe this
> error (Win 10, fpc3.2.2 32
On Mon, Aug 23, 2021 at 12:23 PM Tomas Hajny via fpc-devel
wrote:
>
> Hi *,
>
> Not directly related at all, but while trying to have a look at the
> compiler code related to the error message about the DLL header size, I
> realized that there are quite a few error messages (including this one)
>
On Mon, Aug 23, 2021 at 10:49 AM Florian Klämpfl via fpc-devel
wrote:
> Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only
> 32 Bit DLLs.
I have no idea how to test this.
Mind you: a simple test program with {$linklib common} fails for me
for either 32 or 64, wether
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
I have now f
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 tested and perf
1 - 100 of 181 matches
Mail list logo
