[fpc-pascal] Cross-compilation for OS/2 target

[Tomas Hajny]

On 2026-05-07 14:57, 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,

>  .
>  .
>>> Are you sure? There seem to be several very recent cross-emx 
>>> toolchains on
>>> GitHub, for example:
>>> 
>>> https://github.com/komh/cross-os2emx
  .
  .
> 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.

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