# Linux build problems

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

## Recommended Posts

platform: Mandrake Linux 10.0 3.4.0.0.4mdk compiler: GCC 3.4.0 angelscript: 1.10.1WIP1 When I build my project I get
...include/angelscript.h:382: error: size of array 'ERROR_UnsupportedMethodPtr' is negative
Also I find that I cannot run either of the linux makefiles provided on the angelscript homepage. I have yet to investigate that problem. On a related note, the windows of the same game is now available from my website I know it isn't much yet but my plan is to have a level design contest and add more powerups in the near future. If anyone has a solution to my build problems, reply here. If you have any feedback about my game, send it to my forums. Thanks! [Edited by - Aggrav8d on January 2, 2005 3:36:30 PM]

##### Share on other sites
Thats a common hack to force the compiler to issue an error. You just instantiate an array with a size of -1, and the compiler dumps the name of the array out as an error. :D

I'd assume angelscript doesn't know how to bind object methods in your compiler.

##### Share on other sites
I'm just wondering what I should replace that line with so that GCC will stop reporting an error. Are you telling me that GCC can't compile Angelscript?

[Edited by - Aggrav8d on January 2, 2005 10:42:18 PM]

##### Share on other sites
I don't have any Linux environment so I can't test AngelScript on it, but others have been able to successfully use AS on Linux before so my guess is that this is a problem with the configurations probably in the makefile you're using. Isn't the GCC a C compiler? Shouldn't you be using g++? (please excuse my ignorance)

If the compiler is compiling the templated function without actually using it, then you could just comment that line to remove the error (which could be the case if the compiler doesn't handle templates correctly). But if the compiler is actually trying to use that code, then that would mean that the compiler isn't able to determine the size of object method pointers. If that is the case you'll have to remove the code for registering method pointers (manually I'm afraid), and use global C functions instead.

##### Share on other sites
witchlord not always
gcc = GNU Compiler Collection and GNU C Compiler
as collection it encompasses all the compilers including g++, so he may (and i think he is) just be stating which compiler collection he installed/is using.

##### Share on other sites
OK. Thanks for clearing that up for me. [smile]

##### Share on other sites
I seem to remember someone mentioning that they were able to get it working in DevC++. DevC++ uses mingw, so though it's not actually linux, that should mean the code is compatible with GCC. (IIRC, mingw is a windows port of GCC, and is actually several versions behind)

##### Share on other sites
Yes, I currently test the library both on MSVC++ and DevC++/MinGW. I'm sure it should work on Linux with GCC as well, but unfortunately I don't know what has to be done.

Aggrav8d: Can I add your game to the users list now that you've released it?

##### Share on other sites
Yes, please, that's one of the reasons I gave so much detail about it.

I have yet to resolve the problem, I try to avoid Dev-C wherever possible. flame I mean the damn thing won't even let you set the working directory for your project, that's just...sad. /flame

If someone could better explain to me why this array of size -1 is there then i might be able to find the compiler flag that will make the problem go away. Please advise.

##### Share on other sites
The array size of -1 is there because something is terribly wrong if the compiler is trying to use that particular piece of code. Should it be that it is trying to use that code it would mean that the compiler is either unable to work with templates as necessary, or that it cannot determine the size of a pointer to a class method. In either case you won't be able to take the address of a class method for registration with the library if that is the case, and you'll have to write wrapper functions for those cases (use asCALL_CDECL_OBJLAST or asCALL_CDECL_OBJFIRST).

I will add a compile time flag to the library that will let you disable support for class methods. This should make the library more portable, and still let you use the convenience of direct registration of the class methods where supported.

In fact I intend to implement a generic calling convention as well, that will be one that is 100% platform independent. This because there are just too many differences between compilers that it is near impossible to make even cdecl functions fully portable.

I only use Dev-C++ because it lets me test the library with MinGW in a visual environment. This is especially useful when I have to debug the library. Debugging from the command line with GDB is pain, so I'm very happy that Dev-C++ works as well as it does. Still, my preferred environment is MSVC++.

I'll add your game to the users list as soon as possible.

##### Share on other sites
Thanks to a HDD failure I lost all my makefiles for the linux build of my project. :P

I'm still trying to solve the problem, so if anyone has any ideas I'd love to hear from you.

##### Share on other sites
It works for me with gcc 3.3.2, but I have the same problem with sh-elf-g++ 3.4.3. So maybe something changed in gcc between version 3.3 and 3.4. I don't really think the compiler *use* that code, but compilation still fails for any file that includes "angelscript.h". Even for regular angelscript files like as_typeinfo.cpp.

I just commented that line out and everything seems to work fine. All tests in test_feature succeeds for sh-elf (except the ones with alignment bugs.. I've mailed you about them Andreas). For linux there are still some problems for me with the calling conventions (as_callfunc_x86.cpp) but it should not be that hard to fix.

##### Share on other sites
Fredrik (the Anonymous Poster) has identified some differences with the calling conventions on Linux, mainly how classes are returned from functions. It seems that all classes, independent of size and complexity are returned in memory by GCC on Linux. I believe we have been able to correct these problems already, and the fixes will be available with 2.0.0 WIP 3.

I will try to migrate as much as possible of these corrections to AS 1.10.1 as well, though some might not be possible, or require too much work.