Some gotchyas in porting from Visual C++ to g++

Todays technical article is going to go into a couple of issues that we have run across porting from Visual C++ to g++.

I will say right now that I am an application developer, I don’t know the fine details of how the inner workings of the compilers work, so some of this is merely an educated guess as to WHY the problem happens, but the effect and solution is correct.

The first issue for today is a fairly rare situation where g++, upon hitting a certain piece of code that builds fine under Visual C++, gives the helpful error message:

some/source/file.cpp:172: sorry, unimplemented: called from here

Now, I don’t know about you, but I find that error message singularly unhelpful. It took some time to run this one down the first time. It seems  that g++ and VC++ perform some symbol resolution in different passes to each other. Because what this message is saying is that ‘at line 172, you have tried to use __forceinline, or something you reference has a member function that has __forceinline in it, but I do not know what the thing is, so I cannot inline it’.

EDIT: g++ does not have the __forceinline keyword. There is an equivalent which does the same job however

#define __forceinline inline __attribute__((always_inline))

As VC++ has no problem with the same calls, the only real answer must be a compiler difference that allows VC++ to get away with something that g++ doesn’t. The simple solution is to just change __forceinline to inline and let the compiler inline as it sees fit. Otherwise, you will need to hunt down the exact problem and resolve the order of events for g++

The second issue I thought I would raise today is one that actually happens quite commonly on porting from Windows to Linux. This is the case of bad memory management.

On Windows, the way memory is allocated allows for a certain sloppiness in code. While HIGHLY unrecommended, this is the sort of thing that happens in Windows code all the time. The following is a highly simplified example of the problem.

char *str;
str=(char *)malloc(6)
switch (str[0])

Now, as you can see here, the application uses the variable str right after it has been free()’d. On Windows it seems that this kind of thing can be gotten away with. The memory manager on Windows is highly unlikely to either assign this memory address somewhere else, or to mark it as unavailable. On Linux however, you will often find that this kind of code leads immediately to a segmentation fault.

The example above is highly simplified, but illustrates what some of the more complex segmentation faults we have seen boil down to.  If you see an error like this, which works on Windows and not on Linux, check your order of accessing. I know it sounds obvious, but it happens so often in commercial code that I feel it is worth stressing – free memory only when you have REALLY finished with it.

  • Share/Bookmark

Tags: , , , , , , ,

6 Responses to “Some gotchyas in porting from Visual C++ to g++”

  1. d says:

    I keep wondering, which version of g++ you are using. ‘__forceinline’ is no C++ ISO keyword and if my memory doesn’t fool me this keyword isn’t known to g++.

    I would remove it anyway. Crappy VC++ homebrew stuff.

  2. Jusko says:

    Hi. I know this is wrong place to ask about Sacred, but when there be a Linux demo? I want to buy Sacred, but I’ve never played this game, so i want to test.

    Best Regards.

    p.s: sorry for bad English – I’m from Poland.

    • kayman says:

      Try one week rent on (or any other reseller who offer renting :) for a few euros/dollars/gold/platinum/..

      • Liam Dawe says:

        That is not a Demo, that is Renting, Jusko is asking for a demo, people don’t want to fork out for something they may not like when there should be a Demo available.

        • We have had issues with the demo, in that the source code for the demo and the main game is incompatible, the demo was made with an earlier version of the code. We would LIKE to get the demo out, but we have to realistically balance time and budget. When a rental for a week is, what, £1.50 or something, it isnt a fortune. I agree we SHOULD have a demo, but we have to be practical. Where a demo is possible we do it. Where is a demo is merely ‘hard’ we do it, but the sacred demo is beyond that. We have expended a good amount of developer time on it, without success so far.

Leave a Reply

To stop spam, please answer this simple question
What OS do we make games for

Please note: This site is fully moderated