PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: FellipeBr on July 29, 2012, 11:33:10 AM
-
Hi there,
Anyone got HuC to run on Mac OS X?
Tried here, accomplished to compile it but it keeps giving me a "Segmentation Fault: 11" when I try to compile a game.
Any help will be appreciated, thanks!
-
Post a screen grab of the text output when you try to run the compiler, and how did you install everything on OSX?
-
I just compiled the sources from the HuC website and changed a line where it had a OS verifications.
The only input that it gives is Segmentation Fault: 11.
But, if I try to compile .c file with:
#include "huc.h"
main() {
}
it compiles OK, but if I put any HuC function like set_color() it gives me the Segmentation Fault error.
-
did you setup your path variables to have the PCE_INCLUDE directory?
sounds like it can't find the function libraries.
You have to set a PCE_INCLUDE environment variable.
-
PCE_INCLUDE is setted...
Maybe some problem with the environment variable?
Going to try to hardcode the path to see if it works.
-
Tried it, same error...
Don't know what it can be, Segmentation Fault is a memory error no?
-
Memory access error, yeah.
-
What kind of Mac do you have... Motorola-based or Intel-based? HuC might be doing something funky with pointer maths that gcc isn't adjusting for if you've got a Motorola-based Mac.
-
Oh man if you've got a Motorororororora, you're probably hosed.
Well, maybe not.
Wasn't there a HuC for Amiga? lol. Maybe you can build that one and get it working.
Can you show what your environment variable is set to?
-
mine is Intel-based, a Macbook Pro of 2010.
Tonight i'm going to post the variables, but they are right because I changed it and then it could not anymore found huc.h.
Going to try to compile the Amiga one to see if it works too
-
If you have an intel machine, you won't have any luck with the Amiga one.
Seg fault means its accessing memory incorrectly.
What version of the source did you rebuild.
-
The last one, 3.2.1 if I remember correctly.
-
Put all the header files in the same directory as the binary and see if you still get the same problems.
-
Same error, Segmentation Fault 11...
Starting to think about installing windows in here, just to use the compiler ](*,)
-
Same error, Segmentation Fault 11...
Starting to think about installing windows in here, just to use the compiler ](*,)
Just use DOSBox :)
There is a DOS version of HuC
-
I've tried DOSBox too, without luck. It give some weird errors and it doesn't run anything. :cry:
-
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.
-
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.
-
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?
-
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
-
It sounds like you may not have compiled it right even though it built.
Built != working.
-
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?
-
post the source code of the parts it is complaining about, and we can see what's going on.
-
ok, i'm out of my computer now, tonight I post it for you to see it.
Thanks!
-
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?
-
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?
-
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 */
-
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?
-
-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).
-
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:
/* 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!)
-
-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).
Ah, didn't even see it there. I speed-readed through that crap.
yeah. if you turn off the warnings as errors horse shit, it should just work.
on your Mac.
heh. get it.
-
heh. get it.
I get it. :lol:
-
if I remove the -Werror it compiles fine, but then it gives me the Segmentation Fault 11 error on the build of a game.
-
My env variable is set like this:
PCE_INCLUDE=/Volumes/Iceshard/PCEngine/Compiler/include/pce/
I think it's okay because it can grab the huc.h file ok.
-
well, that's interesting. It segfaults even with the base-source code, unmodified.
are you on a 64-bit OS? I wonder if that's causing some kind of retarded issue.
-
Yup, 64 bit here...
It looks like the problem is when it calls the parse() function in main.c
-
parse() itself is a pretty straightfoward routine. Shouldn't be a problem there.
But, it calls blanks() and gch() ( I think that's what they're called )
Both of those routines have problems. Whoever wrote that code wasn't very careful
about their use of promotion from char to int....
Which is probably part of the seg fault error.
Put some printf()'s in the code; call fflush(stdout) after them so they get forced out.
If you can figure out how far it gets, you'll be able to find and probably fix the problem.
And check for an updated gcc version. There is a sequence of the 4.2 series that has problems.
-
I'm not surprised that 4.2.x is being used by default... OSX is apparently BSD-based, and the BSD lines have pretty much stuck with 4.2.x due to newer versions adopting the horrible GPL 3.0.