Dsound undefined reference error when compiling using 5.2.1 binaries
Orochii Zouveleki

Hello! I'll keep it short, I love Allegro.

I've been having problems with Allegro 5.2.1 anytime I try to use something from the Allegro Audio module, it throws the following errors when trying to compile.

Here's the code I'm using.

1||=== Build: Debug in test (compiler: GNU GCC Compiler) ===| 2..\allegro\lib\liballegro_audio-static.a(dsound.cpp.obj)||In function `dsound_open':| 3C:\dev\allegro_winpkg\universal\allegro\addons\audio\dsound.cpp|252|undefined reference to `DirectSoundCreate8@12'| 4..\allegro\lib\liballegro_audio-static.a(dsound.cpp.obj)||In function `dsound_open_recorder':| 5C:\dev\allegro_winpkg\universal\allegro\addons\audio\dsound.cpp|731|undefined reference to `DirectSoundCaptureCreate8@12'| 6||error: ld returned 1 exit status| 7||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 3 second(s)) ===|

I was using Allegro 5.0.10 in a small game thing I'm making which also uses Allegro Tiled, Taglib, and Lua Bridge. It all worked fine in my other PC with Windows XP. Then brought all the things to this other PC, which has Windows 10, and the thing I had just imploded when I tried to run it. So, well, I was going to recompile it to start hammering it here, and nothing worked because I had a different compiler (everything was set to use MinGW 4.7.0). Okay, that's something I expected, so, I took the opportunity to upgrade.

Changed Allegro to 5.2.1 and downloaded MinGW32-w64 with GCC 5.3.0 since I read somewhere it was the right one. I've been having problems everywhere. But this one in particular I really have no idea.

Since it references DirectSound, I've downloaded the small, trimmed version of DirectX9 dependencies from here: http://liballeg.org/download.html specifically the file named dx9mgw.zip, but it just ignores it, either having the corresponding dsound.lib or not the error message persists, maybe it uses a different version?

Added the dsound.lib to the linker, set -ldsound as a linker option, no change, it just doesn't seem to care it is there.

So I was wondering if someone here could help me. Here is my code, and withing it is a bad fix for a problem which is there temporally just for testing (I read somewhere it happens when the compiler used by libraries doesn't match, but thing is, it happens even when I'm using only precompiled Allegro 5.2.1 and its dependencies).
Downloaded from here: http://liballeg.org/download.html#windows_binaries

1void * __gxx_personality_v0=0; 2void * _Unwind_Resume =0; 3 4#include <dsound.h> 5#define ALLEGRO_STATICLINK 6#include "allegro5/allegro.h" 7#include "allegro5/allegro_audio.h" 8#include "allegro5/allegro_acodec.h" 9 10int main(int argc, char **argv){ 11 al_init(); 12 //If I leave this piece of code commented, it works 13 //does nothing as expected but compiles and runs. 14 /*al_install_audio(); 15 al_init_acodec_addon(); 16 al_reserve_samples(100); 17 ALLEGRO_AUDIO_STREAM *stream = al_load_audio_stream("northfair.it", 10, 10); 18 ALLEGRO_MIXER *mixer = al_get_default_mixer(); 19 al_attach_audio_stream_to_mixer(stream, mixer);*/ 20 return 0; 21}

Thanks in advance.


Conceptually, adding -ldsound is the solution, so we just need to get that to work.

If you're using mingw32-w64, then you should be all set, as it has libdsound.a included (e.g. mine is located in F:/msys64/mingw32/i686-w64-mingw32/lib). Could you paste the gcc command you used to compile your program?

Orochii Zouveleki

Actually forgot to say that I'm using Code::Blocks. But here is what the build log says.

1i686-w64-mingw32-g++.exe -Wall -g -I..\allegro\include -c E:\Proyectos\Cpp\Allegro521\test\main.cpp -o obj\Debug\main.o 2i686-w64-mingw32-g++.exe -o bin\Debug\test.exe obj\Debug\main.o -static-libgcc -static-libstdc++ -ldsound C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libdsound.a ..\allegro\lib\liballegro-static.a ..\allegro\lib\liballegro_acodec-static.a ..\allegro\lib\libvorbisfile.a ..\allegro\lib\libvorbis.a ..\allegro\lib\liballegro_audio-static.a ..\allegro\lib\liballegro_color-static.a ..\allegro\lib\liballegro_dialog-static.a ..\allegro\lib\liballegro_font-static.a ..\allegro\lib\liballegro_image-static.a ..\allegro\lib\liballegro_memfile-static.a ..\allegro\lib\liballegro_physfs-static.a ..\allegro\lib\liballegro_primitives-static.a ..\allegro\lib\liballegro_ttf-static.a ..\allegro\lib\liballegro_video-static.a ..\allegro\lib\liballegro_main-static.a ..\allegro\lib\libdumb.a ..\allegro\lib\libFLAC.a ..\allegro\lib\libfreetype.a ..\allegro\lib\libjpeg.a ..\allegro\lib\libogg.a ..\allegro\lib\libphysfs.a ..\allegro\lib\libpng16.a ..\allegro\lib\libtheoradec.a ..\allegro\lib\libzlib.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libgdiplus.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libuuid.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libkernel32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libwinmm.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libpsapi.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libopengl32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libglu32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libuser32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libcomdlg32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libgdi32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libshell32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libole32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libadvapi32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libws2_32.a C:\mingw-w64\mingw32\i686-w64-mingw32\lib\libshlwapi.a

Also I'm using the 32bit version because I'm one of those rare specimens that still have a 32bit OS.
I installed mingw32-w64 5.3.0 by using the automated installer, I'm not pretty sure but at least when I downloaded and copied the DirectX files I got from that bundle never got any overwrite.

I put the -ldsound option at the linker options.


-ldsound needs to be present after the Allegro link lines. Since you're linking to Allegro by specifying the concrete .a files, I think the easiest solution for you would be to add libdsound.a after the Allegro libraries in the associated Code::Blocks linker dialog. You don't need -ldsound if you're adding libdsound.a explicitly.

Orochii Zouveleki

Yeah, it worked! I always get a little confused by the order in the linker, heh.

I managed to compile it, and I also did manage to compile my game too. Though there is an issue I'm having with things tending to hang.

So I did some more tests in this small project.

1void * __gxx_personality_v0=0; 2void * _Unwind_Resume =0; 3 4#include <dsound.h> 5#include <fstream> 6#define ALLEGRO_STATICLINK 7#include "allegro5/allegro.h" 8#include "allegro5/allegro_audio.h" 9#include "allegro5/allegro_acodec.h" 10ALLEGRO_KEYBOARD_STATE *ret_state; 11ALLEGRO_TIMER *timer; 12ALLEGRO_EVENT_QUEUE *event_queue; 13 14int main(int argc, char **argv){ 15 al_init(); 16 al_init_acodec_addon(); 17 al_install_audio(); 18 if(!al_install_keyboard()) { 19 return 1; 20 } 21 al_reserve_samples(100); 22 timer = al_create_timer(1.0 / 60); 23 event_queue = al_create_event_queue(); 24 al_register_event_source(event_queue, al_get_timer_event_source(timer)); 25 al_register_event_source(event_queue, al_get_keyboard_event_source()); 26 al_start_timer(timer); 27 // 28 ALLEGRO_AUDIO_STREAM *stream = al_load_audio_stream("simple_combat_rearranged.ogg", 4, 2048); 29 ALLEGRO_MIXER *mixer = al_get_default_mixer(); 30 al_attach_audio_stream_to_mixer(stream, mixer); 31 // 32 bool running = true; 33 int fCount = 0; 34 // 35 while(running) { 36 ALLEGRO_EVENT event; 37 al_wait_for_event(event_queue, &event); 38 switch (event.type){ 39 case ALLEGRO_EVENT_TIMER: 40 fCount++; 41 if(fCount>300) running = false; 42 break; 43 case ALLEGRO_EVENT_KEY_DOWN: 44 fprintf(stderr, "KEY DOWN\n"); 45 running = false; 46 break; 47 } 48 //al_get_keyboard_state(ret_state); 49 //if( al_key_down(ret_state, ALLEGRO_KEY_SPACE) ) break; 50 } 51 return 0; 52}

It compiles, but for some reason it hangs if I uncomment the al_get_keyboard_state and al_key_down lines. Also it doesn't seem to be registering the ALLEGRO_EVENT_KEY_DOWN. Just to be sure I made sure the keyboard was being installed, and yes, it is, it returns true.

It's pretty weird since I did pretty similar things in 5.0.10, the only other thing being different being Windows 10 instead of XP. My old 5.0.10 binary crashes the same way.

EDIT: Well, as kind-of expected, has nothing to do with Allegro. I tried my game, and voilĂ , keyboard works, no crash. Actually it did crash but crashed in a section where I parse some things in Lua. My compiler seems to be doing random things. I'll check it out by myself, and if anything I'll reinstall/build everything.

Thanks again SiegeLord for your help. And people, stay awesome.


Ah, glad you got it resolved. I was going to try to reproduce it yesterday but I was having trouble with my Windows 10...

Orochii Zouveleki

All Windows 10 has given me in my life is troubles. Heh!

I'm still intrigued/annoyed by those random runtime crashes/hangs I've been having (all I'm doing is splitting some strings), but slowly I think I'll sort them out. After that I'll be finally able to continue with my game.

Edgar Reynaldo
Orochii said:

void * __gxx_personality_v0=0;
void * _Unwind_Resume =0;

Defining compiler symbols like that is sure to cause trouble. If you are getting undefined references to them, it means you're mixing a version of allegro compiled with one version of the compiler with a runtime compiled with a different compiler. Don't mix versions.

Orochii Zouveleki

I read something about that from the place I saw that defining those symbols would temporally fix the problem. So... yeah maybe I should prioritize fixing that.

I am a little unsure of what to do because I get it in my test too, where all I have is the Allegro lib files (all of them static, non debug), the dependencies and the MingW libraries, along with the libdsound.a (which by the way had to download since the compiler I'm using didn't had it).

All the Allegro libraries are from the same bundle found in http://download.gna.org/allegro/allegro-bin/
And the dependencies from http://download.gna.org/allegro/allegro-deps/

I went and checked out the simple test I made by using just Allegro, and these are the build messages.

1||=== Build: Debug in test (compiler: GNU GCC Compiler) ===| 2..\allegro\lib\liballegro-static.a(d3d_display_formats.cpp.obj)||In function `al_d3d_generate_display_format_list':| 3C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp|49|undefined reference to `_Unwind_Resume'| 4C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp|50|undefined reference to `_Unwind_Resume'| 5..\allegro\lib\liballegro-static.a(d3d_display_formats.cpp.obj):d3d_display_formats.cpp:(.eh_frame+0x63)||undefined reference to `__gxx_personality_v0'| 6||error: ld returned 1 exit status| 7||=== Build failed: 4 error(s), 0 warning(s) (0 minute(s), 3 second(s)) ===|

I'm probably using the wrong compiler for Allegro. MingW32-w64 (the 32bit version).
Then there is taglib, but that I know I compiled it before with MingW 4.7.0 so that's not an issue, I'll do it after hammering this.

By now I'll be getting the MingW 5.3.0 instead of the w64 one. Just trying things out. I'll later update with the results of this.

EDIT: Well, finally! Things work well. Installed the MinGW 5.3.0 (not the -w64 one) because I liked it. So objective. Then built Allegro from Sources using MSYS/MinGW. And finally rebuilt TagLib, and voilĂ . That got rid of the _gxx_personality/_Unwind_Resume things and thereby (or so it seems) those pesky "random" hangs.
One final thing though is that for some reason the game hangs just before exiting, and the thing that makes it hang (already checked it) are these lines.
I've got al_uninstall_audio so it probably tries to do it again, so commented it there, I just hope there isn't any leak (I rarely use new constructors but you never know!).

Anyway, huge thanks SiegeLord and Edgar Reynaldo, and the community and the rest of contributors developing this awesome library.


That hang sounds similar to the one in https://www.allegro.cc/forums/thread/616368. I made an issue about it on github so we don't forget: https://github.com/liballeg/allegro5/issues/664

Orochii Zouveleki

Well, I do use al_reserve_samples() but it's working fine as far as I've seen. Though I haven't tried releasing the samples from memory before destroying the mixer/voice (bad, me! bad!).

I'll test out some more ideas around the issue when I get my hands in my "workplace".

I'll take the opportunity and share a video.

(I'm doing an RPG engine as a preparation for a future project, and because fun, right now I'm working on the event interpreter terminology from RPG Maker because why not).
EDIT: By the way, just tested it on WinXP and it works perfectly fine too. I'm happy! :D

Thread #616425. Printed from Allegro.cc