[fpc-pascal] Cross-compilation for OS/2 target (Was: Re: Who is working on getting FreePascal released?)

[Tomas Hajny]

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


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

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