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

On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote: On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote: Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel >

Re: [fpc-devel] Warning: Unicode constant cast with potential data loss

On 2020-09-17 15:37, Martin via fpc-devel wrote: FPC 3.2.0 var   u,u2 : UTF8String; begin   u := #$2267'x';   u2 := #$2267;  // warning Assigning a WideString to a Utf8String works without warning. Assigning a WideChar (2nd line) to a Utf8String causes "Warning: Unicode constant cast with

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

On 2020-11-27 15:34, Bart via fpc-devel wrote: 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

Re: [fpc-devel] Compiler message colour scheme

On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote: 25.11.2020 1:52, Tomas Hajny via fpc-devel: Hi Nikolai, No problem, thanks for testing. Unfortunately, it doesn't work for me under Windows (Win 10 Pro 64-bit) either with the original version or Have you also checked

Re: [fpc-devel] Compiler message colour scheme

On 2020-11-25 14:40, Sven Barth via fpc-devel wrote: Tomas Hajny via fpc-devel schrieb am Mi., 25. Nov. 2020, 13:31: On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote: > 25.11.2020 1:52, Tomas Hajny via fpc-devel: . . How current is your Windows 10? VT100 support was added only

Re: [fpc-devel] Problems building on i386-win32

On 2020-11-25 09:51, J. Gareth Moreton via fpc-devel wrote: Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs, while C:\Windows\System is 64-bit.  Question is, what can I do to resolve it?  I'm not even sure what Common.dll is for. Well, I don't think that it works this way

Re: [fpc-devel] Compiler message colour scheme

On 2020-11-24 19:17, J. Gareth Moreton via fpc-devel wrote: Sorry for being a bit slow - I've been doing my own work on x86. I gave your patch (and new file) a test run on x86_64-win64, and that seems to work fine.  At least the warning messages in the packages appear magenta.  I'll give

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

On 2020-12-10 07:34, Sven Barth via fpc-devel wrote: Am 09.12.2020 um 23:45 schrieb Bart via fpc-devel: Compiled with fpc 3.2.0 on Windows it will output (both 32 and 64 bit): Runtime error 201 at $004015F1 $004015F1 $00407307 Compiled with fpc 3.2.0 on linux X86_64 it will output

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

On 2020-11-26 20:17, Bart via fpc-devel wrote: 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

Re: [fpc-devel] Compiler message colour scheme

On 2020-11-24 01:14, J. Gareth Moreton via fpc-devel wrote: I'd say thie first port of call is "compiler/comphook.pas", line 258: procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s : AnsiString); It looks like a simple "$if defined". Yes, and the more platforms are added,

Re: [fpc-devel] Procedural types returning file types

On 2020-12-18 10:01, Blaise--- via fpc-devel wrote: Hello, The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) fixes the following: ---8<--- // EXPECTED: 'Error: Illegal function result type' // ACTUAL: gets compiled type M = function : file; begin end.

Re: [fpc-devel] Procedural types returning file types

On 2020-12-18 14:06, Sven Barth wrote: Tomas Hajny via fpc-devel schrieb am Fr., 18. Dez. 2020, 11:38: On 2020-12-18 10:01, Blaise--- via fpc-devel wrote: Hello, > The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) > fixes the following: > ---8<--- &

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

On 2020-12-16 12:25, Blaise--- via fpc-devel wrote: On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote: To be correct: Result is not the name of the result value, it is an alias. I did not dispute that. The important point here is: "an alias" to /what/? You can still use the

Re: [fpc-devel] Using -a or -s option forces change to external assembler

On 2021-08-22 20:43, Jonas Maebe via fpc-devel wrote: On 22/08/2021 16:48, Christo Crause via fpc-devel wrote: Would it make sense to implement an alternative interpretation, where the internal assembler is used if specified/default with just an output writer for the -a case? The compiler

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

On 2021-08-23 14:31, Bart via fpc-devel wrote: 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

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

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) hardcoded in ogcoff.pas instead of having these messages in errore.msg and

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

On 2021-08-23 14:25, Bart via fpc-devel wrote: 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

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

On 2021-08-23 14:37, Bart via fpc-devel wrote: 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

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

On 2021-08-23 15:11, Bart via fpc-devel wrote: 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

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

On 2021-08-23 16:20, Marco van de Voort via fpc-devel wrote: Op 8/23/2021 om 3:11 PM schreef Bart via fpc-devel: dows trickery - feel free to complain at Microsoft. ;-) OK, just for my understanding of this: I cannot see the file there (system32) FPC looks for it there Windows just says it's

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

On 2021-08-24 21:32, Bart via fpc-devel wrote: 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)

Re: [fpc-devel] Building a debug version of FPC-main on Windows

On 2021-08-29 16:39, Marco van de Voort via fpc-devel wrote: Op 8/28/2021 om 10:52 PM schreef Werner Pamler via fpc-devel: Am 25.08.2021 um 20:53 schrieb Marco van de Voort via fpc-devel: Sorry. I'm on holiday, and I only check in occasionally at night. Try changing PP= to FPC= Thank you,

Re: [fpc-devel] Cross-compiling and warnings from linker

On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: Jonas Maebe via fpc-devel writes: . . Yeah, I see. However, this file (/etc/fpc.cfg) is part of installation of particular version of FPC provided by corresponding Linux distribution, and is out of control of a person that installs

Re: [fpc-devel] Cross-compiling and warnings from linker

On 2021-11-23 13:17, Sergey Organov via fpc-devel wrote: Tomas Hajny via fpc-devel writes: On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: Jonas Maebe via fpc-devel writes: . . The compiler will still read only 2 configuration files at most, the default for given instance

Re: [fpc-devel] Fix for an annoying error

On 2021-11-30 08:33, J. Gareth Moreton via fpc-devel wrote: Hi Gareth, 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) is

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 2022-01-12 13:38, Martin Frb via fpc-devel wrote: On 12/01/2022 11:51, Marco van de Voort via fpc-devel wrote: On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote: If it's actually now somehow the case that an offer to provide Win64 builds would be refused though, I guess maybe I'll look

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 2022-01-13 10:28, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 3:28 AM Alexander Grotewohl via fpc-devel wrote: 32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as an emulation layer. I believe it's the same one they use for ARM64 too. It should be kept in

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote: - The problem is *NOT* a native 64 bit "ppcx64.exe"  ?    => 64 bit compiled targets don't require "extended" from the ppc, as they themself wont have support fo

Re: [fpc-devel] Questions about cross-compiling (z80)

On 2022-02-11 14:14, Sven Barth via fpc-devel wrote: BogDan via fpc-devel schrieb am Fr., 11. Feb. 2022, 11:09: . . It seems is an IHX format not tzx Also the result for a simple hello world is way too big (over 20k) ! I assume that I'm passing wrong params to ppcrossz80. What params

Re: [fpc-devel] Questions regarding m68k-atari target

On 2022-01-29 15:05, Thorsten Otto via fpc-devel wrote: On Samstag, 29. Januar 2022 14:55:30 CET Karoly Balogh wrote: Yes, but changing this is not trivial in platform independent code, It doesn't have to, if it can be fixed in fpc_readln_end(). Maybe Sven or someone can say more about the

Re: [fpc-devel] Questions regarding m68k-atari target

On 2022-02-01 06:02, Thorsten Otto via fpc-devel wrote: On Samstag, 29. Januar 2022 16:03:32 CET Tomas Hajny via fpc-devel wrote: does it return individual characters, or does it return the whole line at once (the latter being the case for other FPC targets as far as I know)? Just tried

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote: Hello Ondrej, when compiling a program with fpc on Windows, fpc seems to have the console output encoding wrong. Example program (I am using "ä" because I am on german OS, so "ä" is in my DOS Latin and also in my ANSI codepage):

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-31 18:19, Ondrej Pokorny via fpc-devel wrote: On 31.08.2023 17:54, Tomas Hajny via fpc-devel wrote: . . 2) Always use the ansistring version when parsing the comments. Obviously, this increases compilation time for directives parsing somewhat - we could possibly measure

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 15:26, Ondrej Pokorny via fpc-devel wrote: On 30.08.2023 13:49, Mattias Gaertner via fpc-devel wrote: On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote: On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote: [...] Your output is different from mine (using a freshly compiled

Re: [fpc-devel] passing unicode seach paths on windows

On 2023-08-30 13:56, Mattias Gaertner via fpc-devel wrote: Hi, How to pass unicode search paths to fpc? For example when passing a -Fu as UTF8 via a config file "@my.cfg", fpc says: Path: "C:\pascal\...gibberish..." not found Is there some flag I'm missing or does fpc not support unicode

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 17:12, Ondrej Pokorny wrote: On 30.08.2023 17:04, Tomas Hajny via fpc-devel wrote: (only sent to Ondrej instead of the list by mistake, resending it to the list now) . . Interesting, but it doesn't change anything on the fact that my result is different (and correct) and I

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 16:32, Ondrej Pokorny via fpc-devel wrote: . . If you mean https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do, then no, I don't have this option checked. However, even if I had it checked (I don't), it couldn't

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 13:49, Mattias Gaertner via fpc-devel wrote: On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote: On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote: [...] Your output is different from mine (using a freshly compiled trunk compiler): Free Pascal Compiler version 3.3.1 [2023

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 17:23, Ondrej Pokorny via fpc-devel wrote: . . Sorry to bother you with something as trivial: is your t2.pas file really encoded in UTF-8? Because if I compile an ANSI file with the {$codepage utf8} declaration, then I get "correct" output. But obviously this is very wrong.

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-30 23:38, Ondrej Pokorny via fpc-devel wrote: Am 30.08.2023 um 20:21 schrieb Ondrej Pokorny via fpc-devel: . . Having seen the outputs, I think that the compiler just ignores the source file encoding for {$MESSAGE} and {$NOTE}. It reads them always as ANSI and then converts them

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 2023-08-31 17:08, Ondrej Pokorny via fpc-devel wrote: . . :) We are not at the finish yet. Positive outcome will be when it gets fixed in the compiler source. Yes, I know. I checked your patch briefly now and I don't like the fact that it basically duplicates the code of the two original

Re: [fpc-devel] LEA instruction speed

On 2023-10-13 16:25, J. Gareth Moreton via fpc-devel wrote: GetLogicalProcessorInformation returns a Boolean - if false, an error occurred, and is handled as follows: DiagnoseAndExit('Failed during call to GetLogicalProcessorInformation: ' + GetLastError.ToString); GetLastError = 8 indicates

Re: [fpc-devel] fnmatch (linux), where is the external code/symbol located?

On 2023-10-17 13:46, robert rozee via fpc-devel wrote: Op 17-10-2023 om 13:17 schreef robert rozee via fpc-devel: Date: Tue, 17 Oct 2023 09:32:16 +0200 From: Marco van de Voort (1) installing a new compiler, possibly erasing a release (-Ur) compiler with one that isn't. (2) modifying

Re: [fpc-devel] fnmatch (linux), where is the external

On 2023-10-17 15:34, robert rozee via fpc-devel wrote: . . The problem is that the debs install a version (Makefile.compiled files) that is blind for changes to the compiler. If you need a custom compiler, you need to compile lazarus yourself too, either clone it yourself with git or use

Re: [fpc-devel] LEA instruction speed

On October 3, 2023 03:32:34 +0200, "J. Gareth Moreton via fpc-devel" wrote: Hii Kit, >This is mainly to Florian, but also to anyone else who can answer the question >- at which point did a complex LEA instruction (using all three input operands >and some other specific circumstances) get

Re: [fpc-devel] LEA instruction speed

On 2023-10-10 12:19, Marco van de Voort via fpc-devel wrote: Op 10-10-2023 om 11:13 schreef J. Gareth Moreton via fpc-devel: Thanks Tomas, Nothing is broken, but the timing measurement isn't precise enough. Normally I have a much higher iteration count (e.g. 1,000,000), but I had reduced it

Re: [fpc-devel] LEA instruction speed

On 2023-10-09 20:51, J. Gareth Moreton via fpc-devel wrote: Hi Kit, I updated the "blea" test in the merge request so it now displays the processor brand name on x86_64; however, it is not fetched under i386 because CPUID was not introduced until later 486 processors.  I've attached it to

Re: [fpc-devel] LEA instruction speed

On 2023-10-08 13:45, J. Gareth Moreton via fpc-devel wrote: Sorry, ignore last attachment - I forgot to change a line of assembly (it was correct for x86_64-win64!!). Here is the corrected version. Alright, results for this version for AMD A9 9425 under Linux (the same trunk compiler as

Re: [fpc-devel] 47k attachment

On October 13, 2023 03:45:58 +0200, "J. Gareth Moreton via fpc-devel" wrote: Hi, >To whom it may concern, > >I have a new message for the "LEA instruction speed" chain, but it is >currently in holding as it contains a 47k ZIP file (source code only, and a >third-party licence agreement). 

Re: [fpc-devel] LEA instruction speed

On 2023-10-12 20:02, J. Gareth Moreton via fpc-devel wrote: So an update. . . The latest version of blea.pp doesn't compile with a 32-bit compiler - line 76 contains an unconditional reference to R8 register, which obviously doesn't for the 32-bit mode. Tomas

Re: [fpc-devel] LEA instruction speed

On 2023-10-13 09:26, Tomas Hajny wrote: On 2023-10-12 20:02, J. Gareth Moreton via fpc-devel wrote: So an update. . . The latest version of blea.pp doesn't compile with a 32-bit compiler - line 76 contains an unconditional reference to R8 register, which obviously doesn't for the 32-bit

Re: [fpc-devel] LEA instruction speed

the generated code. Tomas On 07/10/2023 16:51, Tomas Hajny via fpc-devel wrote: On 2023-10-07 03:57, J. Gareth Moreton via fpc-devel wrote: Hi Kit, Do you think this should suffice? Originally it ran for 1,000,000 repetitions but I fear that will take way too long on a 486, so I reduced

Re: [fpc-devel] LEA instruction speed

, but the assembler version runs forever - well, certainly much longer than my patience lasts. I haven't tried to analyze the reasons, but that's what I get. Tomas On 03/10/2023 06:30, Tomas Hajny via fpc-devel wrote: On October 3, 2023 03:32:34 +0200, "J. Gareth Moreton via fpc-devel&quo

Re: [fpc-devel] LEA instruction speed

CPUID availability (albeit not 100% reliably), see https://wiki.osdev.org/CPUID, but I didn't use that. Tomas On 11/10/2023 01:47, Tomas Hajny via fpc-devel wrote: On 2023-10-10 13:24, J. Gareth Moreton via fpc-devel wrote: I'm all for receiving results for all kinds of processor

Re: [fpc-devel] LEA instruction speed

On 10/10/2023 11:54, Tomas Hajny via fpc-devel wrote: On 2023-10-10 12:19, Marco van de Voort via fpc-devel wrote: Op 10-10-2023 om 11:13 schreef J. Gareth Moreton via fpc-devel: Thanks Tomas, Nothing is broken, but the timing measurement isn't precise enough. Normally I have a much higher

Re: [fpc-devel] LEA instruction speed

On 2023-10-13 17:08, J. Gareth Moreton via fpc-devel wrote: Interesting!  That's a bug report to send to the maintainers of the framework.  I'll need to have them fix it before I'd be willing to try again with its use in FPC. Removed the reference.  Apologies - I'm rushing a bit. BTW, it's

Re: [fpc-devel] Unicode RTL for FPC

On 2023-01-13 11:22, Mattias Gaertner via fpc-devel wrote: On Sun, 8 Jan 2023 08:46:37 +0100 (CET) Michael Van Canneyt via fpc-devel wrote: [...] Should have been make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler This does not install the new compiler, so I used the

Re: [fpc-devel] Just need to double check the size of Integer

On 2022-11-24 14:13, J. Gareth Moreton via fpc-devel wrote: Hi Kit, I just need to double-check something.  Under CPU16, SizeInt and SizeUInt are declared as follows:   SizeInt = Integer;   SizeUInt = Word; Is Integer 16-bit in this case? I always thought Integer was defined as a signed

Re: [fpc-devel] Just need to double check the size of Integer

On 2022-11-24 14:25, Ondrej Pokorny via fpc-devel wrote: Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel: On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote: I just need to double-check something.  Under CPU16, SizeInt and SizeUInt are declared as follows:   SizeInt

Re: [fpc-devel] Question on constref

On 2023-02-01 15:40, Hairy Pixels via fpc-devel wrote: On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel wrote: That's exactly what Adriaan is saying. With const the compiler can choose. With constref, you force it not to copy. But this is not so efficient for small parameter

[fpc-devel] Function for translation "normalized" Unicode strings into strings with composed characters?

Hi *, Do we have a function in FPC RTL or packages allowing to translate a string containing letters followed with standalone combining characters (diacritics) into the combined alternatives? I assume that the necessary information is available in the UnicodeData unit, thus an alternative

Re: [fpc-devel] BUG REPORT: Fail to compile when using the out keyword instead of var

On 2023-06-19 09:25, Michael Van Canneyt via fpc-devel wrote: On Sun, 18 Jun 2023, Dylan Lamb via fpc-devel wrote: [image: fpcbug.png] This is not a bug. You're using mode fpc, in which the "out" keyword is not supported. You have 3 possibilities to activate this: . . One additional

Re: [fpc-devel] {$push} and {$pop} on trunk [2024/02/13] for aarach64 doen't work

On 2024-02-13 20:59, Kirill Kranz via fpc-devel wrote: Hi Kirill, I have: . . I believe that you should create a bug report for this issue if you haven't done so yet. Apart from that, I'd suggest configuring your e-mail client for sending a plain text version of your posts to the

[fpc-devel] HTML e-mails in the list (Was: Re: {$push} and {$pop} on trunk [2024/02/13] for aarach64 doen't work)

On 2024-02-16 10:06, Michael Van Canneyt via fpc-devel wrote: On Fri, 16 Feb 2024, Hairy Pixels via fpc-devel wrote: His email looks good to me. Much easier to see code with formatting. Who doesn't have email clients with HTML support these days? I can't imagine how old your system must be

Re: [fpc-devel] ""make clean" builds ppc1 [[Re: Getting error building fpc for clang 16]]

9. prosince 2023 18:24:10 SEČ, Martin Frb via fpc-devel napsal: >On 09/12/2023 17:03, Martin Frb via fpc-devel wrote: >> Anyway, I changed the make >> make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3  OPT=" -Clv16.0 " >> LLVM=1 >> >> Then next it fails, with the same error on >>    

Re: [fpc-devel] dos go32v2 compile target on target?

On 2024-02-27 11:14, Marģers . via fpc-devel wrote: Should I be able to compile DOS go32v2 target from DOS itself? Overcoming some challenges was possible to compile fpc 3.2.2 with starting compiler version 3.2.2. Version 3.2.0 does not work. compiling trunk using "make" fall into infinite

Re: [fpc-devel] error target i386 -Cp80486

On 2024-04-23 11:50, Marģers . via fpc-devel wrote: 1) does not work make clean singlezipinstall OS_TARGET=win32 CPU_TARGET=i386 ALLOW_WARNINGS=1 OPT=" -O2 -vxitl -Cp80486 -Op80486" hangs on system.inc(421,2) Start reading includefile