OS/2, eCS & ArcaOS - Technical > Programming
Software ports - the state of my art until now
Mentore:
--- Quote from: Dave Yeo on November 19, 2025, 04:53:27 pm ---Which assembler is being used? If GAS, don't need the OMF, if NASM, -f aout
--- End quote ---
OK, this is becoming confusing. The problem is here:
make[2]: Entering directory 'D:/Sviluppo/sorgenti/hatari/build'
[ 9%] Building C object src/cpu/CMakeFiles/UaeCpu.dir/cpustbl.c.o
cd D:/Sviluppo/sorgenti/hatari/build/src/cpu && D:/USR/BIN/cc.exe -DCONFDIR=\"/etc\" @CMakeFiles/UaeCpu.dir/includes_C.rsp -O2 -DOS2 -Zomf -std=gnu99 -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -Wimplicit-fallthrough=2 -Wshadow=local -Wvla -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DNDEBUG -Wno-sign-compare -Wno-unused-variable -fwrapv -Wno-shadow=local -Wno-unused-but-set-variable -MD -MT src/cpu/CMakeFiles/UaeCpu.dir/cpustbl.c.o -MF CMakeFiles/UaeCpu.dir/cpustbl.c.o.d -o CMakeFiles/UaeCpu.dir/cpustbl.c.o -c D:/Sviluppo/sorgenti/hatari/build/src/cpu/cpustbl.c
emxomf: Index too large
{standard input}: Assembler messages:
{standard input}: Fatal error: emxomf failed
make[2]: *** [src/cpu/CMakeFiles/UaeCpu.dir/build.make:137: src/cpu/CMakeFiles/U
aeCpu.dir/cpustbl.c.o] Error 1
It's using cc as compiler (gcc 9.2.0 set by cmake). As I said before, I would like to swap it with Gcc 15.10 but just have to investigate on this.
Any clues? I'm pretty much lost...
Mentore
Dave Yeo:
Tried building this. My cmake environment seems broken when it comes to using make, it seems to recurse until it hangs the system, so I use Ninja to build, "cmake -G Ninja .."
Had to work around, I think, our termio not supporting 57600 baud with some #if 0.
Dies here,
--- Code: ---emxomf: Index too large
emxomfld: a.out to omf conversion failed for 'src/cpu/UaeCpu.a'.
ninja: build stopped: subcommand failed.
--- End code ---
Investigating but I'd guess there is inline assembler that needs adjusting for aout, probably .section directives. Aout is very simple.
My quick hack,
--- Code: ---diff --git a/src/rs232.c b/src/rs232.c
index 8175421b..a731cdd7 100644
--- a/src/rs232.c
+++ b/src/rs232.c
@@ -396,10 +396,12 @@ static bool RS232_SetBaudRate(int nBaud)
{ 9600, B9600 },
{ 19200, B19200 },
{ 38400, B38400 },
+#if 0
{ 57600, B57600 },
{ 115200, B115200 },
#ifdef B230400 /* B230400 is not defined on all systems */
{ 230400, B230400 },
+#endif
#endif
{ -1, -1 }
};
diff --git a/src/scc.c b/src/scc.c
index c37197c4..9eb61030 100644
--- a/src/scc.c
+++ b/src/scc.c
@@ -770,11 +770,13 @@ static void SCC_Serial_Set_BaudRate ( int Channel, int value )
switch (value)
{
+#if 0
#ifdef B230400 /* B230400 is not defined on all systems */
case 230400: new_speed = B230400; break;
#endif
case 115200: new_speed = B115200; break;
case 57600: new_speed = B57600; break;
+#endif
case 38400: new_speed = B38400; break;
case 19200: new_speed = B19200; break;
case 9600: new_speed = B9600; break;
--- End code ---
Lars:
In case "nasm.exe" is used as the assembler:
why can you not use switch "-f obj" to produce an OMF object file right away ? That would be the equivalent to calling the C compiler with the "-Zomf" switch which will also produce an OMF object file.
That's at least the nasm switch I used to compile some SSE3 assembler code (unfortunately, alp.exe does not support SSE3) to link with a few other (OMF) object files with Watcom. And that worked without a problem.
Dave Yeo:
You can use -f obj along with USE32 but then all the other object files have to be compiled with -Zomf in the CFLAGS/CXXFLAGS, also need AR=emxomfar, runlib=echo, and different LDFLAGS.
In this case their doesn't seem to be any assembler unless it is inline assembly, I didn't look that close. The build does something weird here, (all one line)
--- Code: ---[87/195] Generating cpustbl.c, cpuemu_0.c, cpuemu_11.c, cpuemu_13.c, cpuemu_20.c, cpuemu_21.c, cpuemu_22.c, cpuemu_23.c, cpuemu_24.c, cpuemu_31.c, cpuemu_32.c, cpuemu_33.c, cpuemu_34.c, cpuemu_35.c, cpuemu_40.c, cpuemu_50.c
--- End code ---
And also builds a 20MB static library which is what fails. Possibly it really does end up with too large an index.
If it was a configure based build, I'd try going OMF all the way and perhaps emxomfar would work better then ar in building the static lib.
Mentore:
--- Quote from: Dave Yeo on November 25, 2025, 08:22:08 am ---You can use -f obj along with USE32 but then all the other object files have to be compiled with -Zomf in the CFLAGS/CXXFLAGS, also need AR=emxomfar, runlib=echo, and different LDFLAGS.
In this case their doesn't seem to be any assembler unless it is inline assembly, I didn't look that close. The build does something weird here, (all one line)
--- Code: ---[87/195] Generating cpustbl.c, cpuemu_0.c, cpuemu_11.c, cpuemu_13.c, cpuemu_20.c, cpuemu_21.c, cpuemu_22.c, cpuemu_23.c, cpuemu_24.c, cpuemu_31.c, cpuemu_32.c, cpuemu_33.c, cpuemu_34.c, cpuemu_35.c, cpuemu_40.c, cpuemu_50.c
--- End code ---
And also builds a 20MB static library which is what fails. Possibly it really does end up with too large an index.
If it was a configure based build, I'd try going OMF all the way and perhaps emxomfar would work better then ar in building the static lib.
--- End quote ---
Hi Dave, thank you and thanks everyone.
Fact is - I really don't know much about CMake. The makefiles it creates always give me a headache ???
If it were made via configure it would be (somewhat) easier. I'll try and figure out what can I do - Hatari would be a good piece of software to have on an OS/2 architecture.
I'll let you all know how things are going.
In the meantime I got Zork source code and some Z-Machine interpreter - will take a look also at these.
Mentore
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version