Segfault running against mercurial-compiled dll

orthecreedence

Hello. I built orx from source using the bitbucket mercurial repo, and compiling with MSYS/MinGW-4.8.1 It builds fine via premake ("embedded dynamic debug") and produces an orxd.dll file.

However, when I link against the DLL and run the resulting executable (which runs fine when using the sourceforge-downloaded release version) I get a segfault.

MinGW's GDB tells me the segfault happens in the b2StackAllocator. I tried to grab the source for Box2D and compile it outside of the Orx tree but then orx won't link against it (missing references).

I'm wondering what process (as well as MinGW gcc version) is used to build/link against Box2D in the MinGW release version. No matter how many configurations I've tried, I either can't build the orx DLL, or whatever I link to it segfaults (in Box2D) at startup.

I'd like to start playing with making changes to the engine, but can't do it when I can't run my changes. Thanks for any help!

iarwain

Hi!

Yes, MinGW/gcc tend to break ABI compatibility with new releases. Orx's MinGW binaries are compiled with gcc 4.6.2 as it was the default version coming with MinGW for a long time.
I now see that gcc 4.8.1 is the de facto version so I'll be updating all the binaries on the repository, probably in a separate branch at first, as I did with gcc 4.7.2 a while ago, but I'll eventually merge it back in a week or two as soon as the thread branch gets merged back to default.

If you don't want to wait for me to update those binaries (probably in a day or so), you can compile all the dependencies yourself, however you can't use vanilla versions of external dependencies. In most cases I had to patch a few bugs or even add new features (like custom gravity support that is not part of the vanilla Box2D distribution).

The dependencies needed at runtime currently are GLFW, Box2D, libsndfile, SOIL and openal-soft. When the thread branch will be merged back into default, the SOIL dependency will go away.

However it's slightly more complicated than simply recompiling those dependencies in the case of openal-soft and GLFW as you'll need to embed some external libraries directly into the libraries you'll obtain. There are more details in this thread, the interesting parts probably being after post #6135.

PS: Lastly, you'll need to have header/libraries for DirectX when compiling openal-soft otherwise the DirectSound backend for the library won't be available and sound support will be more than sketchy.

orthecreedence

That all makes sense. I figured it was a MinGW versioning issue. Recompiling the deps sounds fairly complicated, especially since they don't have ready-to-generate gmake/premake support (at least not that I could find). I'll wait for the newly compiled dependencies. Thanks!

iarwain

It is not as bad as it sounds, but every dependencies has its own set of build projects. I added codelite projects for those which didn't have any MinGW makefile or CMake project but I wasn't courageous enough to add prenake projects to all of them. It would definitely be a nice to have though if someone feels courageous enough.

iarwain

I've pushed the MinGW binaries done with gcc 4.8.1: https://bitbucket.org/orx/orx/branch/mingw-gcc-4.8.1

However compiling orx with gcc 4.8.1 brings back an optimization bug that appeared in the past with specific versions of gcc, mostly affecting orxFX updates. Debug builds are not affected, however if you were to run my playground, name Bounce, after compiling orx, you'll notice all the objects would disappear after finishing their fade in.

I'll try to find the exact reason of what is going on here (it's been coming on and off with gcc for years now but never with clang/msvc) in the coming days.

iarwain

Added a simple work around for the gcc optimization bug: https://bitbucket.org/orx/orx/commits/3084903c6f5cd4e28317904bcc4005006a91a424

Things look functional with gcc 4.8.1 as far as I can tell with my quick tests. Lemme know if you encounter any issues.

orthecreedence

Wow, thanks for the quick turnaround. I'll see if I can get the latest running tonight. I'm not using any Fx yet, so either way probably won't run into issues, but I'll let you know if I do.

orthecreedence

Hey, getting this when trying to compile (MinGW32, 4.8.1, Windows 7, premake gmake). Any ideas?

==== Building orxLIB (embedded dynamic debug) ====
Creating obj/Embedded Dynamic Debug/orxLIB
orxPlugin_EmbeddedList.cpp
g++: error: Dynamic: No such file or directory
g++: error: Debug/orxLIB/orxPlugin_EmbeddedList.d: No such file or directory
orxLIB.make:414: recipe for target 'obj/Embedded Dynamic Debug/orxLIB/orxPlugin_EmbeddedList.o' failed
make[1]: *** [obj/Embedded Dynamic Debug/orxLIB/orxPlugin_EmbeddedList.o] Error 1
Makefile:20: recipe for target 'orxLIB' failed
make: *** [orxLIB] Error 2

iarwain

It looks like the makefile you're using has space issues in the path.
Did you generate it with the premake version found in orx/extern/premake/bin/windows or with a vanilla one? I remember fixing a similar bug back when I decided to switch to premake.

orthecreedence

I used the vanilla one on the premake site (latest beta version). I'll give the packaged one a shot and let you know how it goes.

orthecreedence

That did it! Got it built and running, no segfaults or anything. I'm excited to start hacking away. Thanks for the help!

iarwain

I'm glad it's working. Sorry for the slow start, MinGW is often a bumpy road for the first setup.

sonicbhoc

I'm having the same problem while building against the thread branch. Was this fix applied to the thread branch too, or just the main branch?

iarwain

The binaries made with gcc 4.8.1 are in their own branch as mentioned earlier: https://bitbucket.org/orx/orx/branch/mingw-gcc-4.8.1, they are not directly in the default nor the thread branches, if that was the question.

sonicbhoc

When will the branches be merged? It looks as if the mingw branch hasn't been updated in a month. Were any significant changes made since then?

iarwain

The mingw branch won't change. I'll merge it back to default after the thread one has been merged.

I need to update the iOS plugins to support asynchronous resources, and as soon as this is done, all the merging can happen. So hopefully before the end of the week.

sonicbhoc

Cool, I'll be waiting.

iarwain

That took a bit more time than anticipated, but since last night the thread branch got merged back into the default one and I also upgraded MinGW32: now the gcc being used is 4.8.1.

Now to make an official release!