OS/2, eCS & ArcaOS - Technical > Programming

Software ports - the state of my art until now

<< < (2/3) > >>

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