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
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
