Sign in to follow this  

What is needed to compile cleanly on osx?

This topic is 2661 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've tried to compile the latest version of angelscript on osx, and it's not working. I'm using gcc 4.2.1 (also tried with 4.0 and 4.0.1) and it's having trouble with the 64-bit pieces. Giving me errors similar to those posted in the bsd64 thread. However, I don't know if apple has a later version of gcc, since they integrate their utilities pretty tight, I don't know if I can install gcc 4.4 w/o modifying everything else. I'm not using snowleopard, only leopard, so I don't even know if there is another version of the Xtools that will work here. Any suggestions on getting angelscript working?

Share this post


Link to post
Share on other sites
You can install GCC 4.4 for Mac using MacPorts http://trac.macports.org/browser/trunk/dports/lang/gcc44/Portfile. I don't own any apple machines to test this or give any instructions beyond that it does exist.

This of course isn't a real fix, as the code needs to be fixed to compile on older versions of GCC (Prior to gcc 4.3 I believe, haven't gotten time to confirm that yet). Unfortunately I know next to nothing about assembly, and I don't have a 64-Bit machine for testing, I had to do the FreeBSD testing using Qemu which is very slow.

Share this post


Link to post
Share on other sites
I just knew the answer was going to be macports. <sigh> Is there another version of angelscript that does compile on osx? I'm not installing macports again, It was bad enough the first time, and my opinion of macports is not fit for printing on a public forum, so I'll stop with that question,and hope someone has the info I need. I honestly don't care what version I get, as long as it's a clean compile on a native gcc, 4.x or 3.something. Failing that, I'll just hack the makefiles and build scripts to remove the 64-bit parts of the code then, and just go along w/o them if that's the only solution. I'd rather do that than screw things up with another install of macports.

Share this post


Link to post
Share on other sites
Interesting that you can't compile with 4.2
Have you tried compiling the lastest stable (or SVN) within xcode?
Before the last stable release I emailed the author some changes for compiling under mac os x 64bit that should work as long as you're using xcode. If you're compiling using the makefile, I could see why that may not work though.

Hope that helps a bit,
-Wynter Woods

Share this post


Link to post
Share on other sites
Have you tried compiling it for 64-Bit Mac OS X? I'm sure 32-bit compiles just fine with the older GCC versions, as the code is 64-bit specific.

One option is to force AngelScript to compile in max portability mode and only use the generic calling conventions.

Basically you would need to add the following to as_config.h around line #774

#undef AS_X64_GCC
#undef AS_X86





Just before:

// If there are no current support for native calling
// conventions, then compile with AS_MAX_PORTABILITY
#if (!defined(AS_X86) && !defined(AS_SH4) && !defined(AS_MIPS) && !defined(AS_PPC) && !defined(AS_PPC_64) && !defined(AS_XENON) && !defined(AS_X64_GCC) && !defined(AS_X64_MSVC) && !defined(AS_ARM))
#ifndef AS_MAX_PORTABILITY
#define AS_MAX_PORTABILITY
#endif
#endif





Maybe andreas can recommend a better way of forcing max portability, but that should do it. Unfortunately besides upgrading your version of GCC until someone comes up with a fix this is your only solution.

Share this post


Link to post
Share on other sites
Quote:
Original post by zerotri
Interesting that you can't compile with 4.2
Have you tried compiling the lastest stable (or SVN) within xcode?
Before the last stable release I emailed the author some changes for compiling under mac os x 64bit that should work as long as you're using xcode. If you're compiling using the makefile, I could see why that may not work though.

-Wynter Woods


I had been trying to compile via makefile. When I tried the xcode method though, I got a couple hundred (something like 236) warnings, all about 64-bit values being truncated to 32-bit values, and one error, in the same file that gave me all the suffix errors under the makefile. It wouldn't give me a clue what the error was though, which is odd, I've never encountered that behavior before, usually if there's an error, it's quite specific as to what it is. I'll try the undef suggestion, and see if that fixes anything. Just out of curiosity though, why undef the as_x86 line if the 64-bit part is what's causing the trouble?
Thanks.
*edit*
I added the #undef AS_X64_GCC
line, and got a compile. that took care of the error. Again, this was using the xcode method. I've not (yet) tried using the makefile method again, so that may or may not work, don't know yet. Still had the 236 errors about 64-bit values getting truncated to 32-bit values though, and that's not something I saw via the makefile. Any idea what compiler flag to add to the xcode file to prevent this?
And, just for reference, this is the 2.19.1 release (which is the one posted for download). I've not tried compiling from the latest svn release. May give that a try though, just for the heck of it.
Anyhow, this seems to work now, so off to do some testing. Thanks for the assist.

[Edited by - travis Siegel on August 30, 2010 7:10:48 AM]

Share this post


Link to post
Share on other sites
droz,

There is no need to undefine anything to force the use of generic calling convention. Just define the AS_MAX_PORTABILITY flag manually (no value is needed), either in the as_config.h, or in the project settings themselves.

zerotri,

The code you provided is already in 2.19.1. I think this may be compatibility issue with older versions of xcode. Maybe Travis needs to use the older version of the code.

Travis,

could you post the actual error messages that you're getting? I find it strange that you're receiving a lot of warning messages about 64bit values being truncated to 32bit, but it may hint to possible bugs in the code.

Also, could you make a test for me? Try undefining AS_MAC at the top of the as_callfunc_x64_gcc.cpp file. This will change the code to use a different set of assembly routines that may be compatible with your version of xcode.

as_callfunc_x64_gcc.cpp, around line 59:


#define MAX_CALL_SSE_REGISTERS 8
#define CALLSTACK_MULTIPLIER 2
#define X64_CALLSTACK_SIZE ( X64_MAX_ARGS + MAX_CALL_SSE_REGISTERS + 3 )


// TODO: Should this really be different on Mac and other systems? Probably the Mac way is the correct one
#if defined(AS_MAC)
#define PUSH_LONG( val ) __asm__ __volatile__ ( "movq %0, %%rax\n" "pushq %%rax" :



Just add #undef AS_MAC before the #if defined(AS_MAC) condition. (Remember to undo the changes you did in as_config.h to force max portability mode)



Thanks,
Andreas

Share this post


Link to post
Share on other sites

This topic is 2661 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this