[fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

Hi, I would like to raise some concerns about the current implementation of ordinal bithelpers in r 43417. I do not have the rights to re-open that issue, and I did not want to open a new one for it. My concerns basically are the same I described in the associated bugtracker issue

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

On Sat, Nov 9, 2019 at 9:08 AM Michael Van Canneyt wrote: > That is why I decided to keep it: the mode of sysutils is known and will > never change. A user is supposed to take this into account. OK. > This error was confirmed as a compiler bug. It also disappears if you remove > the inline

[fpc-devel] Request for review of patches for TRegIniFile/TRegistry

Hi, Attached to https://bugs.freepascal.org/view.php?id=35022 I have posted 2 patches for bugs with TRegIniFile. Patch registry.currentpath.diff (3,903 bytes) will fix the issue that CurrentPath (TRegistry) is not updated correctly. Patch reginifile.opensection.diff (831 bytes) fixes a bug in

Re: [fpc-devel] Changes in wiki?

On Thu, Nov 28, 2019 at 9:53 PM Werner Pamler wrote: > > Some time ago I wrote a wiki article on our NumLib > (https://wiki.lazarus.freepascal.org/NumLib_Documentation). Looking at this > page again today I found > that the math expressions are no longer rendered correctly by Firefox, it >

Re: [fpc-devel] Public modifier: brackets or not?

On Sun, Feb 23, 2020 at 4:48 PM Mattias Gaertner via fpc-devel wrote: > The [] is the old syntax. > It bites attributes, so better not use it. Ok, I updated a wiki example that used the old syntax. -- Bart ___ fpc-devel maillist -

Re: [fpc-devel] Typo in docs (TArray)

On Sun, Feb 23, 2020 at 2:08 PM Marco van de Voort wrote: > Docs are mostly unversioned, so there is only "trunk" atm. I corrected > it in SVN Finding where is what in https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/?root=docs isn't always that easy. Thanks for fixing. -- Bart

[fpc-devel] Typo in docs (TArray)

Hi, https://www.freepascal.org/docs-html/rtl/sysutils/tarray.html "it is not needed in Free Pascal, where 2 array types are equal if they element types are equal" "they" should be "their" I was unable to find the trunk version of this, so I'm unsure whether this might already be fixed. --

[fpc-devel] Public modifier: brackets or not?

Hi, I'm a little confused. From: https://www.freepascal.org/docs-html/ref/refsu81.html This page gives 2 examples. Function Second : Real; [Public]; begin Second := 1; end; and Function Second : Real; Public name ’second’; begin Second := 1; end; In the first, Public is in brackets, in

Re: [fpc-devel] Can't access the bug tracker

On Fri, Jan 31, 2020 at 7:00 PM J. Gareth Moreton wrote: > I haven't been able to access the bug tracker for a while now. Is there > a server problem? Same for svn.freepascal.org/cgi-bin/viewvc.cgi/?, the lazarus forum yesterday and the wiki (yesterday). Bart -- Bart

[fpc-devel] Attn: Michael: issue #36663

Hi, In r41784 (make TRegistry unicode-capable) I accidentally broke handling of the Key parameter in the windows implementation of TRegistry.SysCreateKey. This has lead to serious errors in TRegIniFile.OpenSection. I attached a fix to https://bugs.freepascal.org/view.php?id=36663. @Michael:

Re: [fpc-devel] Attn: Michael: issue #36663

On Fri, Feb 7, 2020 at 6:49 PM Michael Van Canneyt wrote: > Done, thanks for the patch. Thanks. That issue got me worried (I broke fpc ...). Thanks to Wallaby for catching that error. Could you mark this revision for merging to 3.2 fixes? -- Bart

Re: [fpc-devel] TEncoding.IsSingleByte is always False?

On Thu, Jan 2, 2020 at 12:57 PM Bart wrote: > Why does TEncoding.ANSI.IsSingleByte return False (and so does > TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and > 850)? It's not Delphi compatible (tested on Dutch Delphi Forum with Delphi XE3. Filed a bugreport:

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

On Thu, Jan 2, 2020 at 8:34 PM Bart wrote: > fpmkunit.pp(4850,16) Error: Incompatible types: got "TStrings" > expected "TStringsOptions" > fpmkunit.pp(9524) Fatal: There were 1 errors compiling module, stopping If I fix that ( on line 4850 change

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

On Thu, Jan 2, 2020 at 9:42 PM Ondrej Pokorny wrote: > It should be fixed with r43846. Yes, thanks. > You may need to delete fpmake.exe and > fpmake.o to make sure they are recompiled. Yes, it failed before that. Good thing you wrote it here. Isn't make clean or make distclean supposed to

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

On Thu, Jan 2, 2020 at 8:42 PM Ondrej Pokorny wrote: > Thanks - I fixed this one. But there seems to be another problem. I am > on it now. Yeah, saw that too ... -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] TStrings and BOM

On Thu, Jan 2, 2020 at 7:15 PM Ondrej Pokorny wrote: > Should be fixed in r43839. Please report any issues. That was quick! Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] Make all fails after revision 43841 (Ondrej)

Hi, After revision 43841 make all in the root fails: make[3]: Leaving directory `C:/devel/fpc/trunk/rtl' make -C fpmkunit bootstrap FPC=C:/devel/fpc/trunk/compiler/ppc386.exe make[3]: Entering directory `C:/devel/fpc/trunk/packages/fpmkunit' C:/devel/fpc/3.0.4/bin/i386-Win32/gmkdir.exe -p

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

On Fri, Jan 3, 2020 at 7:47 AM Sven Barth via fpc-devel wrote: >> Isn't make clean or make distclean supposed to take care of that? >> (Neither of them do) > > I think if you call "make clean" or "make distclean" a second time the fpmake > binaries will be cleaned up as well. No, it doesn't

Re: [fpc-devel] A more fundamental problem Re: i36507

On Fri, Jan 3, 2020 at 11:30 AM J. Gareth Moreton wrote: > Oh right, okay. That explains things then. I would have thought though > that it would have been test-compiled before being pushed to the main > repository. No, the fpc devels are not responsible for Lazarus. The adding of

[fpc-devel] TStrings and BOM

Hi, Would introducing a overload of TStrings.SaveTo* with a 3rd parameter to controle the writing of the BOM be acceptable? Reason: convenience: Fpc 3.2 introduces 2 new behaviours of TStrings: Encoding and WriteBom. For those of us who are used to have UTF8 encode textfile without BOM (and want

Re: [fpc-devel] TStrings and BOM

On Tue, Dec 31, 2019 at 6:37 PM Michael Van Canneyt wrote: > By all means, patches welcome. I can provide a patch for that. If the patch were to be accepted, would it go into 3.2.0? (Otherwise, see my argument for implementing it, it's hardly worth bothering.) PS. Happy New Year to all of you.

Re: [fpc-devel] TStrings and BOM

On Wed, Jan 1, 2020 at 12:25 PM Bart wrote: > > By all means, patches welcome. Patch attached. For completeness I could implement also SaveToStream(AStream, AWriteBom) and SaveToFile(FileName, AWriteBom). B.t.w. Am I correct in understanding that when TStrinsg.SaveTo*() without an encoding

Re: [fpc-devel] TStrings and BOM

On Wed, Jan 1, 2020 at 9:56 PM Ondrej Pokorny wrote: > You replace the WriteBOM property with the AWriteBOM parameter. What's the > point of it? What do you plan to do with the WriteBOM property then? I quote myself (from my fiirst post): > SaveToStream(Fn, TEncoding.UTF8, False) is a one

Re: [fpc-devel] TStrings and BOM

On Thu, Jan 2, 2020 at 12:02 AM Werner Pamler wrote: > To be honest I think Bart's idea of making the BOM an optional parameter > of the Save methods appears to me more efficient than defining a > property just for this only purpose. Do we really have to imitate all > the nonsense dictated by

Re: [fpc-devel] TStrings and BOM

On Thu, Jan 2, 2020 at 1:07 AM Ondrej Pokorny wrote: > But still adding an overload just to omit one line for changing some > property is nonsense. You can do so in a class helper if you want. I did not even consider that option. May indeed be the better choice. -- Bart

Re: [fpc-devel] TStrings and BOM

On Thu, Jan 2, 2020 at 12:36 AM Ozz Nixon via fpc-devel wrote: > Just make your own descendent - jeez. That is noy going to solve my problem. An addition like suggested would have made adjusting code inside Lazarus a bit easier. There are a multitude of TStrings descendants there, I would have

Re: [fpc-devel] TStrings and BOM

On Wed, Jan 1, 2020 at 1:00 PM Bart wrote: Meanwhile, can anybody who has a recent Delphi version comment on this: > B.t.w. Am I correct in understanding that when TStrings.SaveTo*() > without an encoding parameter (so, the 1 parameter version) will NOT > write the BOM if Encoding = nil,

Re: [fpc-devel] TStrings and BOM

On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt wrote: > In Delphi it doesn't matter where the encoding comes from. > If writeBOM is true and there is a preamble for the encoding (whatever it > is), it is used. I think I have to rephrase my question. In fpc TStrings.SaveToStream(AStream)

[fpc-devel] TEncoding.IsSingleByte is always False?

Hi, Why does TEncoding.ANSI.IsSingleByte return False (and so does TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and 850)? According to http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.IsSingleByte : "TEncoding.IsSingleByte specifies whether the current

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On Thu, Dec 26, 2019 at 9:12 PM Ondrej Pokorny wrote: > With all the information from the docs, I am more and more convinced > that TEncoding.SystemEncoding is superfluous and TEncoding.Default > should take over its meaning: TEncoding.Default should reflect changes > in DefaultSystemCodePage.

[fpc-devel] Attn Michael: Issue #0036788: Bad SSL certicificate

Hi Michael, You resolved https://bugs.freepascal.org/view.php?id=36788 as unable to reproduce. However, I have exactly the same problem here: https://www.lazarus.freepascal.org/ gives me the Bad SSL certificate and if I ignore I see the "Apache2 Ubuntu Default Page". It does not redirect me to

[fpc-devel] Winapi modifier: docs r1689

Hi, Isn't this kind of a recursive definition? This modifier allows you to specify the calling conventions for the Windows platform: the compiler will then select the correct calling convention depending on the Windows architecture (cdecl on windows CE or winapi on all other Windows platforms)

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

On Thu, Apr 30, 2020 at 4:45 PM Michael Van Canneyt wrote: Sorry, my reply to Michael went to his private mail, not to the lis, so I copy it here: > It does try to load the one in fpc.cfg, but it is invalid: No it does not. Again: C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vu

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

On Fri, May 1, 2020 at 3:59 PM Sven Barth wrote: > Bart had only replied to me, thus I fully quote his mail here. There is something fishy going on with this ML. Whenever I click on reply in this list, the reply doesn't go to the list, but to th private email of the person I respond to. This

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

On Fri, May 1, 2020 at 4:50 PM Bart wrote: > I'll report back soon. Yeah, it works in the simple test case: C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -Fuc:\pp\units\i386-win32\rtl test.pas -vu Free Pascal Compiler version 3.2.0rc1 [2020/02/29] for i386 Copyright (c) 1993-2020 by

[fpc-devel] Fatal: Invalid PPU-File entry: 242

Hi, Given that I have fpctrunk installed in c:\pp This implies that there is a c:\pp\units\i386-win32\rtl folder and in that folder there is (a.o.) the file system.ppu Now I have a test.pas file that simply consists of "begin end." When I add c:\pp\units\i386-win32\rtl to the units path (yes, I

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

On Fri, May 1, 2020 at 9:12 PM wrote: > when you click where? in what program? i use thunderbird and it has a "reply > list" button that is default for most of the mailing lists i am subscribed > to... The reply button in gmail. But, I just did that tot reply to you, and now it replies tot the

[fpc-devel] FPC now supports Windows 33-bit

Hi, Please don't feel offended, but this typo just made me smile: (And a smile is what we need in these harsh times) Revision 44996 "Moved the common interface part of the win33 and win64 System units to the syswinh.inc include file." -- Bart ___

Re: [fpc-devel] FPC 3.2.0RC1 released!

On Tue, May 19, 2020 at 11:44 AM NetSpirit via fpc-devel wrote: > I don't have an account in bug tracker. I post here to get confirmation > and opinion from other members. > In hope that one, who can create bug reports, will do this. Just make one, not so hard. Unfiled bugreports wiil get

[fpc-devel] Issue #36809: Michael maybe?

Hi, I attached a bugfix to https://bugs.freepascal.org/view.php?id=36809 (Return value ERROR_NO_MORE_ITEMS should not raise an exception in TRegistry.GetKeyNames/TRegistry.GetValueNames) Could this be reviewed and, if no objections, be applied and merged to 3.2 fixes? (It's a regression: 3.0.4

Re: [fpc-devel] Problem with importtl

On Sun, Sep 6, 2020 at 5:56 PM gabor via fpc-devel wrote: > I try to import a type library using "importtl" but it fails - ends with > EAccessViolation exception. I get: C:\Windows\SysWOW64>importtl msdxm.ocx -n Reading typelib from -n ... An unhandled exception occurred at $00439916:

[fpc-devel] Wrong reference to bugtracker in svn log

Hi, Bugtracker issue #35022 was resolved in r44477. Unfortunately in the bugtracker itself it states the issue is resolved in r44478. The log entry for r44477 states that this revision resolves bug #36809 (that however was fixed in r44429). I stumbled upon this because someone reported a crash

Re: [fpc-devel] Wrong reference to bugtracker in svn log

On Sat, Aug 29, 2020 at 10:12 AM Michael Van Canneyt via fpc-devel wrote: > Both done. Apologies for the mix-up. Thanks. No need to apologize, things like these are just bound to happen at some time in the lifetime of a project like this. -- Bart

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On Tue, Sep 29, 2020 at 3:00 PM Nikolay Nikolov via fpc-devel wrote: > >> fpc -Px86_64 hello.pas > > Doesn't that need a -TWin64 as well? > > It's not needed - Win64 is the default target of the windows-hosted > x86_64 crosscompiler. But it doesn't hurt if you add it. Hah! That will save me

[fpc-devel] Comment in math unit is a bit ambiguous?

Hi, In unit math.pp you can find this comment: 510 { returns random values with gaussian distribution } 511 function

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel wrote: > compile to win32 via: > > fpc -Pi386 hello.pas AFAIK a simple fpc hello.pas will do in that setup. > and to win64 via: > > fpc -Px86_64 hello.pas Doesn't that need a -TWin64 as well? -- Bart

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

On Sun, Sep 27, 2020 at 3:06 PM Florian Klämpfl via fpc-devel wrote: > Thanks, fixed. Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] 29527 notes with just 6 lines of code ;-)

Hi, I stumbled upon this by accident. (Fpc trunk r45606, 32-bit on Win10-64) I managed to have the compiler issue 29527 identical notes for a single soucefile that consists of just 6 lines: === function FileSize(S: STring): Int64; inline; begin FileSize := FileSize(S); //obviously a

Re: [fpc-devel] Might need some help with this one

On Thu, Nov 26, 2020 at 11:10 PM Tomas Hajny via fpc-devel wrote: > Typing 'break.exe' in cmd.exe _does_ make a difference here (it executes > as expected unlike when typing just 'break'). And obviously running > break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) works > as well.

Re: [fpc-devel] Compiler message colour scheme

On Wed, Nov 25, 2020 at 1:31 PM Tomas Hajny via fpc-devel wrote: > I get the following result (regardless from the registry setting): > > dwMode = 3 > SCM: 87 > FALSE C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test dwMode = 3 TRUE Microsoft Windows [Version 10.0.19041.630] -- Bart

Re: [fpc-devel] Might need some help with this one

On Thu, Nov 26, 2020 at 5:00 PM J. Gareth Moreton via fpc-devel wrote: program break; {$apptype console} begin writeln('I am Break'); end. Compiles with fpc 3.2.0 and Delphi 7. Outputs nothing at all with both compilers If I run it inside GDB Delphi 7 of fpc: Starting program:

Re: [fpc-devel] Might need some help with this one

On Thu, Nov 26, 2020 at 6:25 PM Bart wrote: > program break; > {$apptype console} > > begin > writeln('I am Break'); > end. > > Compiles with fpc 3.2.0 and Delphi 7. > Outputs nothing at all with both compilers > > If I run it inside GDB > Delphi 7 of fpc: > Starting program:

[fpc-devel] Different handling of try..except depending on OS?

Hi, Consider this code: program Test; {$apptype console} {$ifdef fpc} {$mode objfpc} {$endif fpc} {$R+} var Arr: array[1..2] of integer; i: Integer; begin i:=5; try try Arr[i] := 1; except writeln('Except block'); end; finally writeln('Finally block');

Re: [fpc-devel] Different handling of try..except depending on OS?

On Thu, Dec 10, 2020 at 7:34 AM Sven Barth via fpc-devel wrote: > That is correct, because without the SysUtils unit (which declared the > Exception type) the RTL can't convert the triggered runtime error to an > exception type that can be caught inside the try ... except ... end block. I would

Re: [fpc-devel] Different handling of try..except depending on OS?

On Thu, Dec 10, 2020 at 7:34 AM Sven Barth via fpc-devel wrote: > It's possibly related to FPC using SEH on Win32 and Win64 instead of the > SetJump/LongJump based exception handling on other platforms. Slight > differences are possible and we'd have to investigate why the later does > not

Re: [fpc-devel] Might need some help with this one

On Thu, Nov 26, 2020 at 4:34 PM J. Gareth Moreton via fpc-devel wrote: > P.S. Also, there seems to be a strange, unrelated glitch. If I rename > the file to "break.pp" and change the program name to "break" (from > breakp), the compiled binary doesn't seem to write output (or it > immediately

Re: [fpc-devel] Might need some help with this one

On Thu, Nov 26, 2020 at 6:52 PM Jonas Maebe via fpc-devel wrote: > "break" is probably a command that's recognised by the cmd shell. Yes it is: C:\Users\Bart>help break Sets or Clears Extended CTRL+C checking on DOS system This is present for Compatibility with DOS systems. It has no effect

[fpc-devel] Commits without log message

Hi, r47600 and r47580 seem to have empty log messages (when viewed with ViewVC: https://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=fpc=log) That's just not very nice IMHO. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Different handling of try..except depending on OS?

> No fpc in your linux vm ? I'm shocked... ;-) Well, no trunk ;-) On Windows I know how to easily switch between using compilers. 3.2.0 is in path and I have some batch files to change that for 3.0.4 and trunk respectively (only in the current console session). I never had the courage to figure

[fpc-devel] Attn Jonas: typo in fix for typo (in comment) in revision 47855

Hi, Sorry that I have nothing better to do with my life right now ;-) In revision 47855 Jonas tried to change a typo: "when SSA will be implented" it should of course have been "when SSA will be implemented" but it was changed into "when SSA will be impelented" -- Bart

Re: [fpc-devel] Fpc does not allow Chr() in type definition. Bug?

On Mon, Nov 9, 2020 at 3:56 PM Anton Shepelev via fpc-devel wrote: > Did you try compiling it with FreePascal in Borland mode? Yes, I did, as the related (and now closed) bugreport shows. Anyhow, it should be fixed now. -- Bart ___ fpc-devel maillist

[fpc-devel] Fpc does not allow Chr() in type definition. Bug?

Hi, Type SubRange = Chr(1)..Chr(2); begin end. This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't. Free Pascal Compiler version 3.3.1 [2020/09/26] for i386 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling test.pas test.pas(2,14) Error: Identifier

Re: [fpc-devel] Generics-related compilation issue

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

Re: [fpc-devel] Generics-related compilation issue

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) 1993-2020 by

Re: [fpc-devel] Generics-related compilation issue

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 Windows) 64-bit Windows:

[fpc-devel] Error: Global Generic template references static symtable

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

Re: [fpc-devel] Error: Global Generic template references static symtable

On Fri, Jan 8, 2021 at 9:00 PM Sven Barth via fpc-devel wrote: >> It seems I cannot use a stand-alone function that is declared in the >> implementation of the unit? > Generics are a stream of tokens that is reparsed when specialized. Functions > declared in the implementation section are

Re: [fpc-devel] Error: Global Generic template references static symtable

On Sat, Jan 9, 2021 at 12:00 PM Sven Barth via fpc-devel wrote: > Right click the error message in Lazarus, then click "Help". For me a dialog > with the following text appeared: Hah! Learned something new today! > The *why* is not important for users. Those that are interested can ask, just

Re: [fpc-devel] Error: Global Generic template references static symtable

On Sun, Jan 10, 2021 at 11:59 AM Sven Barth via fpc-devel wrote: > Displaying the message at the correct location would be more involved... > you might want to open a bug report for that so that it's remembered > somewhere, but it's definitely going to be a low priority one.

Re: [fpc-devel] Generics-related compilation issue

On Mon, Jan 4, 2021 at 12:57 PM Werner Pamler via fpc-devel 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 Windows)

Re: [fpc-devel] Different handling of try..except depending on OS?

On Thu, Dec 10, 2020 at 11:53 AM Michael Van Canneyt via fpc-devel wrote: > > Yes, it should. it's definitely a bug. Done: https://bugs.freepascal.org/view.php?id=38201 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] Attn. Marco: typo in r49563

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

[fpc-devel] Unexpected range check error (64-bit only)

Hi, Something like this: 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). From a mathematical POV, this can never give a range error, max value would be 2147484157 (255 +255

Re: [fpc-devel] FPC 3.2.2-RC1 released!

On Wed, Mar 24, 2021 at 12:25 PM Marco van de Voort via fpc-devel wrote: > >> We have placed the first release candidate of the Free Pascal Compiler > >> version 3.2.2 on our ftp servers. I seem to mis the win32->wince crosscompiler at ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/i386-win32/

Re: [fpc-devel] [Core] Dangerous download on bug report

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.org

Re: [fpc-devel] [Core] Dangerous download on bug report

On Wed, Feb 24, 2021 at 8:36 AM Michael Van Canneyt via fpc-devel wrote: > I am also using Mozilla Firefox. So do I. I have downloaded that file (some time ago) just to see if I could simplify the problem. I had no problems, it was just a zip file with enormous amounst of code with a gazillion

Re: [fpc-devel] [Core] Dangerous download on bug report

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-devel] Installer and %path%

Hi, Just installed 3.2.2RC1. All OK. Just one minor issue. The installer asked me if it was OK to remove the path to 3.2.0 form my systems %path%. I agreed. It then added the path to 3.2.2. However, it did not do that in the place where the path to 3.2.0 was, but added it as last. So on my

Re: [fpc-devel] Building trunk of today fails on Windows: Error:Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

On Sun, Aug 22, 2021 at 1:51 PM wkitty42--- via fpc-devel wrote: > if that Common.dll file is only valid for 64bit windows builds, perhaps the > better thing to do is to wrap the $linklib line in a check to see if you are > building 64bit... if 64bit then loadlib otherwise, noop... seems logical

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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 Tha cannot

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Untranslatable (hardcoded) messages

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Untranslatable (hardcoded) messages (Was: Re: Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size)

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) >

Re: [fpc-devel] Untranslatable (hardcoded) messages

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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 >

Re: [fpc-devel] Untranslatable (hardcoded) messages

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,

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

[fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

Hi, C:\devel\fpc\trunk>git log -1 commit a77f5221f341b32bb964c03dc61c1e80b71714dd (HEAD -> main, origin/main, origin/HEAD) Author: florian Date: Sat Aug 21 20:36:29 2021 +0200 C:\devel\fpc\trunk>make clean C:\devel\fpc\trunk>make all ... [ 19%] Compiled package odbc Start compiling

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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.

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

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

Re: [fpc-devel] Undefined symbol during linking - any suggestions?

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

  1   2   >