[gijoe77]

so I have been working on compiling dgen 1.23 for IRIX with MIPSpro. I'm sort of stuck and wondering if someone with a bit more expertise can give me a pointer.

here is the error:

Code:

bash-4.2$ CC  -g -lm -I/usr/nekoware/include/SDL -D_GNU_SOURCE=1 -D_SGI_MP_SOURCE -lm -o dgen  rc.o romload.o md.o mdfr.o md-joe.o decod
e.o vdp.o save.o graph.o myfm.o fm.o sn76496.o ras.o main.o mem.o -Lsdl -lpd  -Lmusa -lmusa68  -L/usr/nekoware/lib -Wl,-rpath,/usr/nekowa
re/lib -lSDL -lpthread  md-phil.o zz80.o
ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "pow" -- 1st referenced by fm.o.
        Use linker option -v to see when and which objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "sin" -- 1st referenced by fm.o.
        Use linker option -v to see when and which objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "log" -- 1st referenced by fm.o.
        Use linker option -v to see when and which objects, archives and dsos are loaded.  
ld32: INFO    152: Output file removed because of error.
-bash-4.2$

I researched this and I found that I need to link the math library via "-lm", so I did that. The "fm.c" file has the <Math.h> header, it is compiled with -lm, and get when I do "nm fm.o" it show these math library symbols as unresolved..

Anyone have any insight? I included the dir with source and the makefiles I used.

BTW I compiled this with gcc, it loads, shows the sega screen, then segmentation faults - so It might not work anyway (endian issue?), but its a good learning experience for me.

also BTW2 I tackled 1.33, after many hours (and some IRC help) got it to compile with gcc, but then I made a fatal mistake and didn't save everything right then and there - I started making changes to the source again to compile it with MIPSpro and really hit some serious gcc-isms I have no clue how to work around - but I'm currently trying to redo the work I did to get gcc to compile.

ps: anyone have a copy of the wiki from nekochan about guide to porting stuff?

[dexter1]

Try changing the linking order: put -lm at the back instead of early on in the linker options.

Also it might be that there is a header problem when compiling with MIPSPro CC aka c++. Formally one should #include <cmath> for regular c-style math functions or <math.h> for c and c++ source files. If above linking reordering doesn't give you an executable, maybe a header file change in fm.cpp will get you going

[jpstewart]

<QUOTE author="dexter1" post_id="1241" time="1530197855" user_id="141">

Try changing the linking order: put -lm at the back instead of early on in the linker options.

Correct.

It's important to remember that the MIPSpro compilers process .o files and libraries in the order they appear on the command line. Libraries are only used to satisfy unresolved symbols that exist in the files <I>previously</I> named. You sometimes even have to specify a library twice: if liba and lib have circular dependencies, you'll encounter the situation where you need to link with "-la -lb -la".

Conversely, GCC doesn't care about ordering of libraries. It processes everything as a whole. As a result, some Makefiles will need to be tweaked for MIPSpro to put the libraries in the right order.

[gijoe77]

so lets say I just compile fm.c, the resulting fm.o will have unresolved symbols even if <math.h> is included and -lm is specified?

Code:

-bash-4.2$ rm fm.o

-bash-4.2$ cc -DPACKAGE=\"dgen-sdl\" -DVERSION=\"1.23\" -DWORDS_BIGENDIAN=1 -DCOMPILE_WITH_MUSA=1  -I. -I.  -I./sdl  -g -I/usr/nekoware
/include/SDL -D_GNU_SOURCE=1 -D_SGI_MP_SOURCE  -c fm.c -o fm.o -lm

-bash-4.2$ nm fm.o | grep UNDEF
[29]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |malloc
[30]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |pow
[31]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |sin
[32]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |log
[34]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |free
[46]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |memset
[50]    |         0|       4|OBJT |GLOB |DEFAULT  |UNDEF  |mega_dacout
[51]    |         0|       4|OBJT |GLOB |DEFAULT  |UNDEF  |mega_dacen
-bash-4.2$

I just find that interesting - I guess all those get resolved in final linking. I was able to get it to compile with this placement of -lm right after fm.o

Code:

-bash-4.2$ CC  -g -I/usr/nekoware/include/SDL -D_GNU_SOURCE=1 -D_SGI_MP_SOURCE   -o dgen  rc.o romload.o md.o mdfr.o md-joe.o decode.o vd
p.o  save.o graph.o myfm.o fm.o -lm sn76496.o ras.o main.o mem.o -Lsdl -lpd  -Lmusa -lmusa68  -L/usr/nekoware/lib -Wl,-rpath,/usr/nekowar
e/lib -lSDL -lpthread  md-phil.o zz80.o

but it still started then coredumped. Lets say I suspect endian-ness, is this something way above my pay-grade to investigate? heh

One more question - i tried to change <math.h> to <cmath> in fm.c and it really didn't seem to like that:

Code:

-bash-4.2$ rm fm.o
-bash-4.2$ cc -DPACKAGE=\"dgen-sdl\" -DVERSION=\"1.23\" -DWORDS_BIGENDIAN=1 -DCOMPILE_WITH_MUSA=1  -I. -I.  -I./sdl    -g -I/usr/nekoware
/include/SDL -D_GNU_SOURCE=1 -D_SGI_MP_SOURCE  -c fm.c -o fm.o -lm
cc-1005 cc: ERROR File = fm.c, Line = 82
  The source file "cmath" is unavailable.

  #include <cmath>
                  ^

1 catastrophic error detected in the compilation of "fm.c".
Compilation terminated.
-bash-4.2$

Is <cmath> only a gcc header or should my /usr/include have that aswell?

[TruHobbyist]

<QUOTE author="gijoe77" post_id="1248" time="1530205899" user_id="243">

I just find that interesting - I guess all those get resolved in final linking. I was able to get it to compile with this placement of -lm right after fm.o

There are, in a *very* simplistic view, two phases of compilation for native code compilers:

1. from source code in a high level language (C, C++, Pascal, ...) to object code (unbound/unlinked machine code)
2. from object code to executable file

<QUOTE author="gijoe77" post_id="1248" time="1530205899" user_id="243">

-bash-4.2$ cc -DPACKAGE=\"dgen-sdl\" -DVERSION=\"1.23\" -DWORDS_BIGENDIAN=1 -DCOMPILE_WITH_MUSA=1 -I. -I. -I./sdl -g -I/usr/nekoware /include/SDL -D_GNU_SOURCE=1 -D_SGI_MP_SOURCE -c fm.c -o fm.o -lm

The -c flag forces phase 1, so there is no need for -lm which is a flag for the linker (phase 2).

<QUOTE author="gijoe77" post_id="1248" time="1530205899" user_id="243">

I just find that interesting - I guess all those get resolved in final linking.

Bingo!

<QUOTE author="gijoe77" post_id="1248" time="1530205899" user_id="243">

but it still started then coredumped. Lets say I suspect endian-ness, is this something way above my pay-grade to investigate? heh

I would suggest the following:

1. start a debugger (gdb, for example)
2. load the corefile (if dgen dumped core, it has left a file called just that, core, that you can feed into a debugger)
3. print the stack trace to see where it started, what it executed, and where it got nuked

IIRC, in Nekochan someone tried to compile dgen with exactly this issue, and IIRC it was a bus error that caused the core dump. Bus errors, as far as I know, are mainly due to misalignment issues when accessing structure fields.


Keep on your efforts, congrats for that

Tru

[gijoe77]

<QUOTE author="TruHobbyist" post_id="1254" time="1530211162" user_id="84">

I would suggest the following:

1. start a debugger (gdb, for example)
2. load the corefile (if dgen dumped core, it has left a file called just that, core, that you can feed into a debugger)
3. print the stack trace to see where it started, what it executed, and where it got nuked

I've never used a debugger with a core file- but I did have a nice page saved from nekochan about how someone very nicely stepped someone else through loading a core file into a debugger and finding the offending problem - I was planning on studying that when I ran into this sort of issue, but I guess this is just bad timming...

<QUOTE author="TruHobbyist" post_id="1254" time="1530211162" user_id="84">

IIRC, in Nekochan someone tried to compile dgen with exactly this issue, and IIRC it was a bus error that caused the core dump. Bus errors, as far as I know, are mainly due to misalignment issues when accessing structure fields.

what exactly is a misalignment issue?

[commodorejohn]

<QUOTE author="gijoe77" post_id="1273" time="1530333283" user_id="243">

what exactly is a misalignment issue?

Trying to access a value at an address that is not evenly divisible by the size of the value (i.e. trying to load a 16-bit value at an odd byte address.) Some CPUs allow this, some don't.

[gijoe77]

ok - I'm not at the skill level to take on alignment issues so I moved on to dgen 1.33, I was able to finally compile it with gcc - I had to go grab GNU/GNUish copies of features.h, uClibc_config.h, stdint.h and wordsize.h (althought instead of wordsize.h I now realize I could have just done a "#define __WORDSIZE 32" when I ran into that issue...)

I originally put these in /usr/include just to see if it worked, and it did, but I'm sure that can't be good practice so I just moved them into the the dgen src dir and change the includes from <> to "". What is the typical way to handle gcc/GNU header files that are not installed by default MIPSpro/gcc? just put them in the gcc include directory or make a separate one and link to it? Like put them in /usr/local/newincludes and then do a "-I/usr/local/newincludes" ?

Anyway I finally compiled it with gcc and it works! But its pretty slow (I'm doing my current dev work on an o2 - so I know its slow but its slow even by o2 standards). I noticed this spat out at linking (last line with "CXXFLAG -v" added):

Code:

CXXLD  dgen
Reading specs from /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/specs
Configured with: ./configure --prefix=/usr/nekoware --enable-version-specific-runtime-libs --disable-shared --enable-threads --enable-haifa --enable-libgcj --with-included-gettext
Thread model: single
gcc version 3.4.6
/usr/nekoware/libexec/gcc/mips-sgi-irix6.5/3.4.6/collect2 -call_shared -no_unresolved -init __do_global_ctors -fini __do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 -o dgen /usr/lib32/mips3/crt1.o /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/crtbegin.o -L/usr/nekoware/lib -L/usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6 -L/usr/bin -L/usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/../../.. rc.o romload.o md.o mdfr.o decode.o vdp.o save.o graph.o fm.o myfm.o sn76496.o ras.o main.o mem.o ckvp.o joystick.o system.o cz80.o sdl/libpd.a musa/libmusa68.a mz80/libmz80.a -lGL -rpath /usr/nekoware/lib -lSDL -lpthread -lstdc++ -lm -dont_warn_unused -lgcc -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc -warn_unused -dont_warn_unused -lgcc -warn_unused /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/crtend.o /usr/lib32/mips3/crtn.o

ld32: WARNING 84 : /usr/lib32/libGL.so is not used for resolving any symbol.
ld32: WARNING 127: Two shared objects with the same soname, /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.
ld32: WARNING 127: Two shared objects with the same soname, /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.

I would think that if this is SDL using OpenGL, I would want to have "/usr/lib32/libGL.so" used? Does this error message mean the program is not using the native hardware openGL support?

I attached the source and Makefiles if anyone feels like looking at what I did or trying it themselves - Enter key is enter, A button is I guess the A button, its what makes Sonic jump anyway

PS: I'm trying to compile this in MIPSpro now but running into issues - I'm still trying to do my own research but I might head back here in a day or so with a question or two

[TruHobbyist]

<QUOTE author="gijoe77" post_id="1275" time="1530339075" user_id="243">

ok - I'm not at the skill level to take on alignment issues so I moved on to dgen 1.33

Just to point out one more thing: Alignment requirements are very common on RISC CPU-based systems (MIPS, PPC/POWER, Alpha, ARM, PA-RISC, ...), you will see this on any platform (CPU + OS) with RISC CPUs (and derivates like VLIW - it's about order). The reason is efficiency, in a broad sense: design of CPU can be less complex, software can be less complex, execution can be faster, programs can be smaller, and so on.

To put a real life example. RISC would be like <URL url="https://images.scribblelive.com/2017/7/31/be281e3d-65a1-4435-af51-8c75d754f98a_800.jpg">this: an ordered life, with lots of assumptions (you work ~8 hours a day, ~5 days a week, you have to take the bus at a specified hour, you need ~45 min to get to work, ...).

And CISC would be more like <URL url="https://www.deike-online.de/media/image/thumbnail/bu712U69F3-96dpi_720x600.png">this: chaos.

<QUOTE author="gijoe77" post_id="1275" time="1530339075" user_id="243">

I was able to finally compile it with gcc

Congrats!!!

<QUOTE author="gijoe77" post_id="1275" time="1530339075" user_id="243">

What is the typical way to handle gcc/GNU header files that are not installed by default MIPSpro/gcc?

Let's divide header files into two groups: those backed by a library (linked) and those that are not (independent). In both cases a header file functions as an interface for the programmer, but: The linked ones need the corresponding library to be included when linking the executable/DSO.

Mixing, modifying, replacing header files just for hacking, breaking and fixing things is great for learning but a really bad idea (what function prototypes does it include, where is the code for this functions, is it compatible with existing ones, ...).

<QUOTE author="gijoe77" post_id="1275" time="1530339075" user_id="243">

just put them in the gcc include directory or make a separate one and link to it? Like put them in /usr/local/newincludes and then do a "-I/usr/local/newincludes" ?

If just hacking, this would be ok...

The steps I would take when in need of a header file not present on my system, would be:

1. Locate the package/project/whatever the header file is part of
2. Port this package/project/whatever to your platform (MIPS/IRIX) <-- here is where you adapt the header files and underlying libraries, if any, to work on your platform
3. Install it somewhere on your system
4. Use them in your source code


<QUOTE author="gijoe77" post_id="1275" time="1530339075" user_id="243">

I noticed this spat out at linking (last line with "CXXFLAG -v" added):

Code:

CXXLD  dgen
Reading specs from /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/specs
Configured with: ./configure --prefix=/usr/nekoware --enable-version-specific-runtime-libs --disable-shared --enable-threads --enable-haifa --enable-libgcj --with-included-gettext
Thread model: single
gcc version 3.4.6
/usr/nekoware/libexec/gcc/mips-sgi-irix6.5/3.4.6/collect2 -call_shared -no_unresolved -init __do_global_ctors -fini __do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 -o dgen /usr/lib32/mips3/crt1.o /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/crtbegin.o -L/usr/nekoware/lib -L/usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6 -L/usr/bin -L/usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/../../.. rc.o romload.o md.o mdfr.o decode.o vdp.o save.o graph.o fm.o myfm.o sn76496.o ras.o main.o mem.o ckvp.o joystick.o system.o cz80.o sdl/libpd.a musa/libmusa68.a mz80/libmz80.a -lGL -rpath /usr/nekoware/lib -lSDL -lpthread -lstdc++ -lm -dont_warn_unused -lgcc -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc -warn_unused -dont_warn_unused -lgcc -warn_unused /usr/nekoware/lib/gcc/mips-sgi-irix6.5/3.4.6/crtend.o /usr/lib32/mips3/crtn.o

ld32: WARNING 84 : /usr/lib32/libGL.so is not used for resolving any symbol.
ld32: WARNING 127: Two shared objects with the same soname, /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.
ld32: WARNING 127: Two shared objects with the same soname, /usr/lib32/mips3/libm.so and /usr/lib32/libm.so, have been been linked. This is probably due to a missing -L specification. Ignoring the latter.

I would think that if this is SDL using OpenGL, I would want to have "/usr/lib32/libGL.so" used? Does this error message mean the program is not using the native hardware openGL support?

Maybe dgen does not use OpenGL/GL directly but indirectly through SDL (which in turn has been compiled and linked against OpenGL/GL).
You can check with the ldd command:

# ldd dgen
... should output libSDL at some entry ...

# ldd libSDL.so
... should output libGL at some entry if compiled/linked against it ...


Regards,

Tru

[gijoe77]

<QUOTE author="TruHobbyist" post_id="1279" time="1530351742" user_id="84">

Maybe dgen does not use OpenGL/GL directly but indirectly through SDL (which in turn has been compiled and linked against OpenGL/GL).
You can check with the ldd command:

# ldd dgen
... should output libSDL at some entry ...

ah duh - I knew that but had a complete brainfart. I've been sleeping and seeing c code at this point so im sort of scrambled. "ldd dgen" does show it's using /usr/lib32/libGL.so


quick question - What's the deal with MIPSpro and inline functions? Does it not support "inline"?

for example for this error:

Code:

cc-1020 cc: ERROR File = m68kcpu.h, Line = 883
  The identifier "inline" is undefined.

  INLINE uint m68ki_read_imm_16(void);
  ^

I just did a "#define INLINE" at the start of the header (which I'm not sure is the best way to handle it) and for this issue:

Code:

cc-1020 cc: ERROR File = system.h, Line = 57
  The identifier "inline" is undefined.

  static inline uint16_t h2le16(uint16_t v)
         ^

I just went ahead and deleted "inline" from the declarations. Is this normal for MIPSpro? If so does this "inlining" analysis get triggered by using the -INLINE:x flag or just higher level optimization dictates what would be inlined if the compiler deemed said function/routine worthy of inlining? I've been reading up on this a bit and if I am understanding what I am reading it seems even with gcc, putting "inline" in the declaration doesn't guarantee a function or routine getting "inlined" if the compiler analysis doesn't think it should be...

also on this topic, If I am understanding what I am reading I thought "inline" was a c99 standard? If thats the case isn't MIPSpro a c99 compliant compiler? (did a "c99" command exist in earlier versions of MIPSpro? seems c89 is still there)

thanks

edit: here is the main thing I've been reading about inline functions <URL url="https://www.greenend.org.uk/rjk/tech/inline.html">https://www.greenend.org.uk/rjk/tech/inline.html