HuC on Mac OS X

[FellipeBr]

I've tried DOSBox too, without luck. It give some weird errors and it doesn't run anything. 

[RegalSin]

About this, try running windows 1.0, or maybe an enviorment within an enviroment setup.

OSX, is a terrible opperating system on a terrible machine, OS Next was a great idea at first but after OS9 is one big plunge into darkness.

The only good thing about the system is terminal, which should give you access to the Unix it is built on?

I hate the hardware the machines is built on. I have the worlds most fastest pc, and it sits in my room like a giant heatsink. I mean that really, I rub my feet against it sometimes, to keep cool.

[FellipeBr]

well, i'm not here to discuss if OSX is or is not a good operational system.
I'm here to try to make the HuC work on it, unsuccessfully yet.

[Arkhan]

well, i'm not here to discuss if OSX is or is not a good operational system.
I'm here to try to make the HuC work on it, unsuccessfully yet.

Ignore RegalSin.

He's retarded.


Do you have the screen grabs of your environment variables, etc.?

Also did you try just using the Linux one? 

 When you compiled it, did you get any warnings?

[FellipeBr]

Arkhan, going to post the screen of the enviroment variables and the errors tonight.
Yup, tried with the Linux one, same error.
It was giving me some compilation errors like duplicated () like if ( (flag == 1) ) and etc
and some convertion errors in unsigned char * to char * and etc.
But I think I solved all of them, but still it gives me the Segmentation Fault 11 error

[Arkhan]

It sounds like you may not have compiled it right even though it built. 

Built != working.

[FellipeBr]

oh, I see...
Well, I think I removed all the errors, but maybe i'm wrong.
Do you think you can help me to compile it right then?

[Arkhan]

post the source code of the parts it is complaining about, and we can see what's going on.

[FellipeBr]

ok, i'm out of my computer now, tonight I post it for you to see it.

Thanks!

[FellipeBr]

So, let's start:

The first error is a OS check in main.c, since it does not have a validation for Mac OS X, it throws an error...

main.c:540:4: error: Add calling sequence depending on your OS

The validation:

#ifdef DJGPP
   exe = "pceas.exe";
   opts[i++] = "pceas.exe";
#elif defined(linux) || defined(unix)
   exe = "pceas";
   opts[i++] = "pceas";
#elif defined(WIN32)
   exe = "pceas.exe";
   opts[i++] = "pceas.exe";
#else
  #error Add calling sequence depending on your OS
#endif

So i change the #error by exe = "pceas"; opts[i++] = "pceas";

The next one is:


main.c:58:19: error: equality comparison with extraneous parentheses
      [-Werror,-Wparentheses-equality]
                                        if ( (*(p+1) == 'd') ) {

Because of the ( ) around the equality. Removing that the error goes away.

Then, it start the most comum one (appears in a lot of places):


expr.c:39:7: error: assigning to 'unsigned char *' from 'char *' converts
      between pointers to integer types with different sign
      [-Werror,-Wpointer-sign]
        expr = &prlnbuf[*ip];

This one I think it's because of the char definition, with the unsigned.
How can I solve that? simply removing the unsigned?

[Arkhan]

What version of GCC are you using?

Also, those parens are fine.   Screw it saying they aren't.

Can you give more context for the last error?   

[FellipeBr]

GCC 4.2.1

But, if it gives an error in that parens the compilation doesn't go further no?
There is a way to ignore that?

That last error occurs in expr.c:

the code:

int
evaluate(int *ip, char last_char)
{
   int end, level;
   int op, type;
   int arg;
   int i;
   unsigned char c;

   end = 0;
   level = 0;
   undef = 0;
   op_idx = 0;
   val_idx = 0;
   value = 0;
   val_stack[0] = 0;
   need_operator = 0;
   expr_lablptr = NULL;
   expr_lablcnt = 0;
   op = OP_START;
   func_idx = 0;

   /* array index to pointer */
   expr = &prlnbuf[*ip];

the expr in expr.h:

unsigned char *expr;   /* pointer to the expression string */

[Arkhan]

You said using DOSBox didn't work?

I am not sure why it forces you to remove parens.   It shouldn't. 

I forget how to, but there is a way to force the compiler to enter a mode that ignores alot of errors and continues on.   Are you sure these are not warnings being treated as errors?

[nodtveidt]

-Werror should be removed from the build process... it turns warnings into errors and can break compilation, even if the resulting binary is technically correct or the warnings are insignificant (such as uninitialized variables and the like).

[NightWolve]

Hm, it's being strict on data types, yeah, this *should* normally be a warning. Either what Rover says, or, to fix that one change to:

Code: [Select]

/* array index to pointer */
expr = (unsigned char*)&prlnbuf[*ip];

That's it! You could also remove the 'unsigned' from the variable's definition in "expr.h" like you said, but that might cause other issues forcing more casts elsewhere. Best to just explicitly use a cast like above so that the compiler knows you're aware that the data types are different. (They're pointers though, so if it's 32-bit compiled, they're always 4 bytes no matter the data type that they point to... it shouldn't error out on this without an explicit cast!)