There's very little activity about fixing the lack of a release of FreePascal that
(a) is in the last 4 years.
(b) runs on Mac OS
(c) is included, and able to be included on debian. (d) is back on homebrew.
(e) can be built/bootstrapped on current Mac OS with current XCode.

The list of painted-into-corners probably extends further than this.

Who is working on what, and what is wide open for contrib help?

Warren

Warren Postma wrote

There's very little activity about fixing the lack of a release of FreePascal that

You're missing a huge discussion on fpc-devel :-)

If Florian didn't make the 3.2.4 release by july, I will take over.

Tentative plan (if/when I take over):
- try to merge some more stuff from devel to fixes.
- get another RC out.
- If nothing serious pops op, release main platforms in september.

All offers of help are appreciated.

If you know of fixes in trunk that can be merged cleanly to fixes, then let us know.

Michael.

I'm not on fpc-devel either. May I ask to summarize the discussion in a few sentences?

I'm also eagerly waiting for the next release. Not for 3.2.4, but for 3.4.0. Imho, it'd be desirable to have yearly releases with only some enhancements and new features instead of waiting for big steps for more than 6 years.

Just my 2 cts.
Kind regards,
Thomas

Thomas Kurz wrote

I'm not on fpc-devel either. May I ask to summarize the discussion in a few sentences?

I'm proposing to automate more to achieve half-yearly releases.

We currently use only a fraction of what gitlab offers. I believe that we can automate a large part of what should be fixes releases.

Major releases (like 3.4.0) will obviously require more testing, but that should not stop us from releasing more fixes.

Others are not convinced that this would help and believe human or organisational problems are the real cause of the delay.

This is not wrong, but my view is that by diminishing the burden of creating a release by making it more efficient, the human and organisational problems will be less big and easier tackled.

I'm also eagerly waiting for the next release. Not for 3.2.4, but for 3.4.0. Imho, it'd be desirable to have yearly releases with only some enhancements and new features instead of waiting for big steps for more than 6 years.

Everyone is agreed on the problem.

Agreeing on the solution proves more difficult.

Michael.

BST Thomas Kurz wrote

I'm also eagerly waiting for the next release. Not for 3.2.4, but for 3.4.0. Imho, it'd be desirable to have yearly releases with only some enhancements and new features instead of waiting for big steps for more than 6 years.

What environment and architecture are you on?

I've started making unofficial releases of FPC 3.3.1 ('main' - aka 'trunk'). I started this mainly because I have software that requires features in FPC 3.3.1 that others wanted to test too - and I simply can't sit around for a few more years, waiting for the FPC team.

Think of it as "FPC Community Edition" releases. ;-) These will come out monthly.

I'm considering merging in a few outstanding MRs too for those releases (after I did a round of triaging).

https://github.com/graemeg/fpc-opdf-releases

ps: I'll probably rename the project at some point.

Regards,
Graeme

Perhaps the general aura of decrepidness is being affected by the fact that the forums are down also
https://forum.lazarus.freepascal.org/index.php
--> 504

I am a mac, linux, and windows dev, I'll join the devel list, and see what I can do.

On Mon, Apr 20, 2026 at 2:02 AM Michael Van Canneyt via fpc-pascal <

Me too.

I'm building the Win32 and Win64 within a Docker container on Linux, keeping the same directory structure which the official Lazarus builds use. It builds Lazarus trunk and FPC trunk. I've attached the build script; maybe it can help someone.

It's certainly possible to build other platforms (Linux, DOS, macOS, OS2, whatsoever), but I don't need them. That's why I focused on Windows only.

Thomas

Unfortunately, you cannot build OS/2 releases of FPC on Linux, because the needed port of GNU binutils is not available there. It might be possible to build it from Gitlab CI using the SSH runner if you have a running OS/2 instance with SSHD.

Tomas

Hi,

Are you sure? There seem to be several very recent cross-emx toolchains on GitHub, for example:

https://github.com/komh/cross-os2emx
https://github.com/neozeed/crossemx-binutils-2.9.1

So at least the EMX cross-build seems possible? Not sure what you do use for the native OS/2 port.

Charlie

Op 20-4-2026 om 13:24 schreef Graeme Geldenhuys via fpc-pascal:

Snapshots of trunk (what are essentially straight builds) are made daily:

https://downloads.freepascal.org/fpc/snapshot/v33/x86_64-linux/

Karoly Balogh wrote

On Tue, 21 Apr 2026, Tomas Hajny via fpc-pascal wrote:

Hi Charlie,

.
.

Many thanks, I wasn't aware of them. Both of them seem to be fairly new. The latter doesn't contain any release, it looks like an attempt in an early stage, but the former looks very promising (and comes from a developer known for his various OS/2 ports, thus very likely to be working well - I cannot check it immediately, but I'll do so later for sure). It's good that things have moved forward in this area. :-) I'll still need to check whether our makefiles work well in this case, but even if not, this could be fixed for sure.

Tomas

Le 21/04/2026 à 10:33, Marco van de Voort via fpc-pascal a écrit :

These snapshots are not limited to x86_64-linux target, you can find many more targets on the up directory: https://downloads.freepascal.org/fpc/snapshot/v33

Pierre

BST Marco van de Voort wrote

Snapshots of trunk (what are essentially straight builds) are made daily:

Thanks, I knew about those, but they don't contain the new OPDF debugger support (Merge Request: https://gitlab.com/freepascal.org/fpc/source/-/ merge_requests/1409) that others wanted to test.

Regards,
Graeme

Snapshots of trunk (what are essentially straight builds) are made daily: https://downloads.freepascal.org/fpc/snapshot/v33/x86_64-linux/

Finding those is really hard.

And those are not installers, they're tarballs.

Find a recent installer, there isn't one.

On Tue, Apr 21, 2026 at 1:36 AM Marco van de Voort via fpc-pascal <

Thanks, I knew about those, but they don't contain the new OPDF debugger support (Merge Request:

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1409) that others wanted to test.

Agree. Shouldn't there be builds of some feature or experimental branch with everything, even what is not in trunk?

I mean we can use fpcup to do our own builds if we're not technical enough to do our own.

But I think part of a project's core infrastructure is full nightly INSTALLABLE builds. (not just bin tarballs)

On Tue, Apr 21, 2026 at 11:05 PM Graeme Geldenhuys via fpc-pascal <

No. They might be not in main because they are simply broken or the wrong approach. And filtering that is simply unnecessary work.

Regards,
Sven

Tomas Hajny wrote

On 2026-04-21 10:21, Karoly Balogh via fpc-pascal wrote:

.
.

FWIW, an update on this topic:

1) The binaries provided with cross-os2emx don't work with Debian oldstable (BookWorm) running on my machine, but they work with Debian stable (Trixie), i.e. this is no problem.

2) For some reason, the (cross-)linker complains about a duplicate symbol in the OS/2 RTL. From a technical point of view, the complaint is correct and I can resolve it, but it's strange that I don't get such a complaint when linking natively. However, no big deal.

3) The ported emxbind doesn't accept the same parameters as the native version. That surprises me (I wouldn't expect a port to Linux to behave differently from the original OS/2 program), but it's no problem to fix it (the unsupported parameters are related to EMX binaries able to run under both OS/2 and DOS natively and that is not supported for the OS/2 target anyway - unlike the EMX target - so I can simply skip them for the OS/2 target).

4) Unfortunately, I get another error from emxbind (i.e. the final linking stage transforming the generated a.out file to OS/2 EXE): "emxbind: invalid data segment (does not start with 0xba0bab)". That's certainly not something I could fix myself - it suggests that probably either the ported as version, or the ported ld linker create something not expected by emxbind. I'll experiment with it a bit more to locate the culprit (it might be an error in the emxbind port as well) and try contacting author of the port in order to get some support from him. I suspect that he might be using emxomfld instead, thus not working with emxbind at all, but binaries created that way cannot be debugged with gdb (or anything else) and, moreover, I couldn't make emxomfld to work for me with FPC compiled binaries when experimenting with this option in the past.

Stay tuned...

Tomas

Tomas Hajny wrote

On 2026-04-21 11:11, Tomas Hajny wrote: > On 2026-04-21 10:21, Karoly Balogh via fpc-pascal wrote:

Hi,

.
.

The update promised earlier - after my report of the problem mentioned in point 4 above, the latest release 1.2.0 of the cross-os2emx project allows successful cross-compilation of OS/2 binaries under Linux (obviously with a 32-bit FPC compiler) together with my 2 fixes (one for the loader file within the OS/2 RTL, another for the linker parameters) which should be hopefully included with the 3.2.4 release (without these changes, one must compile with -s and modify the linker parameters manually). Needless to say, it's useful to create symbolic links for the cross-os2emx binaries in order to allow FPC finding the assembler (as), linker (ld) and linking post-processor (emxbind) with the expected prefixes (i386-os2-). In addition, it should be possible to use this solution on a MS Windows machine as well if combined with WSL (Windows Services for Linux). ;-) Direct compilation of the cross-os2emx sources to native MS Windows executables might be possible as well, but I didn't try that and the author of the cross-os2emx port doesn't provide MS Windows binaries (perfectly understandable decision as far as I'm concerned :-) ).

I didn't try building a complete OS/2 release with this setup yet, but I might test it later; if nothing else, I assume that some additional make parameters would be necessary compared to native building in order to use zip rather than tar as expected for OS/2, but it should be perfectly doable. Regardless from that, I'll continue building the OS/2 release under OS/2 natively, it's just to provide alternatives for anybody possibly interested.

Tomas