Compilation problems with OpenAL under win32 / mingw

khkramer commented

2015-10-11 08:48:45 +00:00

(Migrated from github.com)

For example:

C:/Ruby21/lib/ruby/2.1.0/i386-mingw32/socket.so: [BUG] Segmentation fault

I've tried different versions of ruby.
This only happens when I use your windows build, I can load gems with an old version I've compiled myself, any idea what might cause this?
Unfortunately I haven't been able to succesfully compile mkxp myself lately due to the compiler complaining about some missing OpenAL references..

For example: `C:/Ruby21/lib/ruby/2.1.0/i386-mingw32/socket.so: [BUG] Segmentation fault` I've tried different versions of ruby. This only happens when I use your windows build, I can load gems with an old version I've compiled myself, any idea what might cause this? Unfortunately I haven't been able to succesfully compile mkxp myself lately due to the compiler complaining about some missing OpenAL references..

Ancurio commented

2015-10-11 10:42:03 +00:00

(Migrated from github.com)

I think both libruby and the gems must have originated from the same build, otherwise all bets are off. Since the version of ruby I used for the win build is very likely different from what you have installed on your system, it's bound to run into problems.

So if you want to use the latest mkxp source with gems, compiling yourself is probably the sanest choice. Maybe we should look at those OpenAL errors instead?

I think both libruby and the gems must have originated from the same build, otherwise all bets are off. Since the version of ruby I used for the win build is very likely different from what you have installed on your system, it's bound to run into problems. So if you want to use the latest mkxp source with gems, compiling yourself is probably the sanest choice. Maybe we should look at those OpenAL errors instead?

khkramer commented

2015-10-11 11:16:10 +00:00

(Migrated from github.com)

So it doesn't use the ruby dll in the same folder if present?

Yeah that might be better, I'll post them here in a few.

So it doesn't use the ruby dll in the same folder if present? Yeah that might be better, I'll post them here in a few.

Ancurio commented

2015-10-11 11:22:36 +00:00

(Migrated from github.com)

The win build has everything statically linked in, that's why you don't see any other dlls either (except fluidsynth). Besides, switching out dlls like that underneath the exe might bring problems of its own, especially with something as complex as MRI, which in 99% of cases isn't used as a shared lib anyway and thus likely doesn't have a strong focus on API stability.

khkramer commented

2015-10-11 12:52:09 +00:00

(Migrated from github.com)

Alright so I'm getting these errors during linking:

CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x1490): undefined reference to `_imp__alSourceQueueBuffers'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x14a8): undefined reference to `_imp__alGetSourcei'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x153d): undefined reference to `_imp__alSourcePlay'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x15a2): undefined reference to `_imp__alSourcePlay'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x200b): undefined reference to `_imp__alGetSourcei'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x2069): undefined reference to `_imp__alSourceStop'
CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x20fc): undefined reference to `_imp__alSourceStop'

I've tried different versions of OpenAL, recompiling openAL, nothing worked for me.
This is on Ubuntu 14.04

Alright so I'm getting these errors during linking: ``` CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x1490): undefined reference to `_imp__alSourceQueueBuffers' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x14a8): undefined reference to `_imp__alGetSourcei' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x153d): undefined reference to `_imp__alSourcePlay' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x15a2): undefined reference to `_imp__alSourcePlay' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x200b): undefined reference to `_imp__alGetSourcei' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x2069): undefined reference to `_imp__alSourceStop' CMakeFiles/mkxp.dir/objects.a(alstream.cpp.obj):alstream.cpp:(.text+0x20fc): undefined reference to `_imp__alSourceStop' ``` I've tried different versions of OpenAL, recompiling openAL, nothing worked for me. This is on Ubuntu 14.04

Ancurio commented

2015-10-11 16:29:10 +00:00

(Migrated from github.com)

Oh ok, so this is with mingw. Are you linking against OpenAL dynamically or statically?

Googling for the imp_ prefix, there are mentions that a faulty declspec(dllimport) declaration of functions in a header could be responsible for this.

Oh ok, so this is with mingw. Are you linking against OpenAL dynamically or statically? Googling for the _imp__ prefix, there are mentions that a faulty `declspec(dllimport)` declaration of functions in a header could be responsible for this.

khkramer commented

2015-10-11 17:03:50 +00:00

(Migrated from github.com)

The link.txt generated by CMake contains this:

-Bstatic -lOpenAL32 -lz -Wl

So I assume it's trying to link OpenAL statically.

The link.txt generated by CMake contains this: `-Bstatic -lOpenAL32 -lz -Wl` So I assume it's trying to link OpenAL statically.

Ancurio commented

2015-10-11 18:07:54 +00:00

(Migrated from github.com)

So there's your problem; the dllimport tells the compiler to look for _imp__ prefixed symbols because it thinks it's linking against a dll, but then you're telling the linker to do it statically, so they don't exist. Either link against the dll, or ensure that the dllimport prefix is the OpenAL headers is not set.

From looking at al.h, the first thing you could try is telling cmake to -DAL_LIBTYPE_STATIC, which will drop the dllimport.

So there's your problem; the `dllimport` tells the compiler to look for `_imp__` prefixed symbols because it thinks it's linking against a dll, but then you're telling the linker to do it statically, so they don't exist. Either link against the dll, or ensure that the `dllimport` prefix is the OpenAL headers is not set. From looking at `al.h`, the first thing you could try is telling cmake to `-DAL_LIBTYPE_STATIC`, which will drop the dllimport.

khkramer commented

2015-10-29 20:29:10 +00:00

(Migrated from github.com)

Sorry for the late response.

I've tried compiling a fresh clone with passing that option to the cmake flags, but it still throws the same errors when linking.

I've done some googling as well and I can't seem to find a solution, I'm also not very experienced with this stuff in general so that doesn't really help..

Any other things I could try?

Sorry for the late response. I've tried compiling a fresh clone with passing that option to the cmake flags, but it still throws the same errors when linking. I've done some googling as well and I can't seem to find a solution, I'm also not very experienced with this stuff in general so that doesn't really help.. Any other things I could try?

Ancurio commented

2021-11-07 20:50:15 +00:00

(Migrated from github.com)

I will upload a working mingw-w64 depkit soonish that should render this issue void.

Compilation problems with OpenAL under win32 / mingw #134