So you're compiling a script with only a global variable? Then the problem is with the execution of the @init function which is called automatically by the engine after compiling the scripts.

It seems that the bytecode is not properly attributed for this function for some reason. The code breaks on line 1031, which is "switch( *(asBYTE*)l_bc )", right? What is the value of l_bc at this moment? Is it null (shouldn't be)?

Could you compile the library with AS_DEBUG flag defined, and then show me the output file __@init.txt that should be generated in the folder AS_DEBUG (under the working directory). This ought to show the bytecode for the function that was compiled. It will probably look something like this:

Temps:     0   0 *    RET      0

At least if you're compiling the script "float i;".

Another thing. Would it be possible for you to try the test_feature project, compiled with the flag AS_MAX_PORTABILITY? That should run a few tests that works on my machine and hopefully on yours as well.

Regards,
Andreas

Is it GCC you 're using in OS X?
If yes, could you run the following in a terminal and post its output here?

touch foo.hcpp -dM foo.h

Yiannis.

Jeffrey,

I think it will be very difficult for me to discover what's going on because I have no way of debugging the code. Would it be possible for you to debug the library to see if you can discover why the l_bc pointer is null?

Also, how about registering a username on GDNet? It's free. [smile]



mandrav,

Just out of curiousity, what would that show you? I'm not as familiar with GCC as you are. I know that touch will create an empty file (if it doesn't exist already) but what will 'cpp -dM' do?

Also, could you confirm that the latest version still works on 64bit systems without your changes? If it does, then it is likely that I need to do something slightly different on PPC 64, than for AMD 64. Perhaps it is due to the little-endian/big-endian differences?



Regards,
Andreas

Quote:

Original post by WitchLord mandrav, Just out of curiousity, what would that show you? I'm not as familiar with GCC as you are. I know that touch will create an empty file (if it doesn't exist already) but what will 'cpp -dM' do? Also, could you confirm that the latest version still works on 64bit systems without your changes? If it does, then it is likely that I need to do something slightly different on PPC 64, than for AMD 64. Perhaps it is due to the little-endian/big-endian differences? Regards, Andreas

Could be an endianness issue but that is for you to check Andreas :)
The command I posted above will dump all built-in preprocessor symbols so we can see if _LP64 is defined or, if not, which symbol is defined that tells us it's 64bit system. This way we can better refine the preprocessor conditionals inside AngelScript. So instead of using "#ifdef _LP64" in code, we could define a "#define AS64" (for example) in as_config.h (based on more than _LP64) so at least the pointer arithmetic works as expected...

As for my changes:
I 've decided that the coming weekend I 'll send you all my changes, no matter what state they 'll be in (i.e. not finished). I think it might be better if we could get one or two more helping hands on this as I 'm nearing the release date for Code::Blocks 1.0rc3 and my free time will be limited.
So, anyone who has posted the interest to help, check back around the weekend ;)

Yiannis.

Yes, of course. I didn't mean for you to validate the endianess. Sorry if I gave that impression.

I'll have to remember that command for GCC. It looks like it could come in handy in the future as well.

I'll accept the code you have even though it may not work 100%. Surely others will be able to help out validating it and rooting out the bugs that remain.

Regards,
Andreas

Quote:

Original post by Anonymous Poster The define to determine whether it's a 64 bit or not on OS X is __LP64__ instead of _LP64.

That's good. This is defined here too so, Andreas, it's safe to use __LP64__ instead of _LP64 to catch both cases.

Yiannis.