Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Dependency Binaries

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Dependency Binaries
roger levy
Member #2,513
July 2002

So it turns out the binaries I have aren't loading the acodec dependencies. Too bad! No sound for you!

:(

Having somehow avoided building Allegro from sources in Windows since at least as far back as 2015, and since having at some point reclaimed all the space doing so robbed from my paltry 250GB SSD, I'm not looking forward to the prospect of having to re-download and install all that's needed and build every single last dependency along with, just to make certain I don't have to dive into this territory again until the next time I have to upgrade to get the fix for a showstopping bug.

Could someone who's already generated Win32 binaries of the dependencies of 5.2.2.x kindly help me out? Binaries would be just fab. Or the simplest possible path to accomplishing my goal of building them as fast as possible and getting back to working on games and stuff...

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

Thank you! But, my bad, I forgot to mention, I'm using the dynamic binaries, so I need all the dynamic dependencies! Do you have those?

EDIT: Plus a dynamic binary of Allegro that will load them...

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Yes, everything is included. static and dynamic versions of everything (enet, flac, freetype2, libpng, zlib, physfs, turbo (libjpeg), ogg, theora, vorbis, dumb (static only)). As well, there are dynamic debugging executables, demos, and tests, as well as html and chm docs and all the includes and libs you need for everything.

roger levy
Member #2,513
July 2002

Oh! Money. :)

I don't want to bother you, but can I contact you any time I need binaries in the future? This is a thing I'd like to not have to worry about anymore if possible.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

Sounds good. Thanks for performing this service. :)

Unfortunately it didn't seem to work, I'm still getting null from al_load_audio_stream. Groan...

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

I tried a couple mp3's. Both threw error "could not create stream"

I tried a mod file as well. It actually hung up and after a while crashed.

EDIT: the mod file didn't work but an XM file did. and so did an ogg file. so mp3 isn't supported... makes sense; patents.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

Still not able to stream an ogg file in my project; I'm tearing my hair out, seems like this happens every time I upgrade. I even found a bug where somehow the file string was being clobbered. Will keep trying...

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

I am initializing the acodec addon. I am also in the folder with all the DLL's both when the Allegro DLL is loaded and when I call the al_init_acodec_addon function.

Boy I kind of wish I could step into it right now! Some detailed error reporting in this case would be VERY helpful. I just want to know if the dependencies were loaded or not.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

roger levy
Member #2,513
July 2002

This is all Greek to me. Due to a distaste for / lack of aptitude for the C multiverse and a strong will I have managed to weasel past the complexity and I just use SwiftForth and DLL's. That's it. Will gdb work with any EXE, even if it's not in C? (Not that I hold out much hope.)

I managed to get Process Explorer to show me what DLL's are loaded by my process. Looks like everything is there. I am literally doing just (the equivalent of) this...

al_init()
al_init_acodec_addon()
al_install_audio()
foo = al_load_audio_stream( path, 2, 2048 );

and foo is null. double triple checked everything.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Okay, well I didn't know you were using SwiftForth. Try compiling it as a C program first.

set path=c:\mingw\bin;%PATH%
cd program_folder
g++ -Wall -g -o test.exe -Ic:\allegro5\include test.cpp -Lc:\allegro5\lib -lallegro_monolith-debug.dll

set path=c:\allegro5\bin\dlls;c:\mingw\bin;
gdb test.exe
break test.cpp:LINE_NUMBER
run
bt

roger levy
Member #2,513
July 2002

I will give that a try. Just succeeded in loading a WAV file on a whim.

UPDATE:

Decided to try a faster way first. I enabled the debug binary, and checked out allegro.log. Here is the output:

stdio    D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109  file_stdio_fopen                 [   0.00000] opening C:\Users\Roger\Dropbox\Programs\SwiftForth_3.5.3\SwiftForth\bin\allegro5.cfg r
system   D E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:771  _al_win_safe_load_library        [   0.00000] PathFindOnPath found: C:\WINDOWS\system32\shcore.dll
system   D E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:682  load_library_at_path             [   0.00000] Calling LoadLibrary C:\WINDOWS\system32\shcore.dll
system   I E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:685  load_library_at_path             [   0.00000] Loaded C:\WINDOWS\system32\shcore.dll
system   I E:\LIBS\LIBS71Build\allegro\src\system.c:257  al_install_system                [   0.00000] Allegro version: 5.2.3 (GIT)
audio-dsound I E:\LIBS\LIBS71Build\allegro\addons\audio\dsound.cpp:255  _dsound_open                     [   0.00028] Starting DirectSound...
audio-dsound D E:\LIBS\LIBS71Build\allegro\addons\audio\dsound.cpp:264  _dsound_open                     [   0.04107] DirectSoundCreate8 succeeded
audio    I E:\LIBS\LIBS71Build\allegro\addons\audio\audio.c:347  do_install_audio                 [   0.04522] Using DirectSound driver
acodec   I E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:204  _al_load_ogg_vorbis              [   0.04537] Loading sample ../../../temp/asdf.ogg.
stdio    D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109  file_stdio_fopen                 [   0.04539] opening ../../../temp/asdf.ogg rb
system   W E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:775  _al_win_safe_load_library        [   0.04764] PathFindOnPath failed to find libvorbisfile-3.dll
acodec   W E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:97   init_dynlib                      [   0.04770] Could not load libvorbisfile-3.dll
acodec   I E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:204  _al_load_ogg_vorbis              [   0.04777] Loading sample ../../../temp/mus_mode.ogg.
stdio    D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109  file_stdio_fopen                 [   0.04779] opening ../../../temp/mus_mode.ogg rb
stdio    D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109  file_stdio_fopen                 [   0.04792] opening ../../../temp/palmroad.wav rb
wav      I E:\LIBS\LIBS71Build\allegro\addons\acodec\wav.c:107  wav_open                         [   0.04809] Ignoring chunk: smpl
wav      I E:\LIBS\LIBS71Build\allegro\addons\acodec\wav.c:107  wav_open                         [   0.04811] Ignoring chunk: JUNK
dtor     D E:\LIBS\LIBS71Build\allegro\src\dtor.c:196  _al_register_destructor          [   0.04820] added dtor for sample 1F4AD228, func 6788375D

Looks like libvorbisfile-3.dll fails to load, due to PathFindOnPath failed... but I'm in the same directory as that file. Makes no sense.

I have updated my Allegro version number that I pass to al_init to 5.2.3, thinking that was it. No luck.

Another update: Just tried copying all dependencies to C:/windows, and it succeeds. The heck.

Update the third: Tried copying them to the folder where my actual IDE's EXE is located. That worked too. I'm starting to think that this is a Windows 10 security thing. Disallow loading of DLL's that seem to be not related to the current process.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

When a DLL is loaded, the %PATH% is what is searched, starting with .\. That means the current working directory needs to be the same as the one with your exe and dlls. Do NOT put DLLs in system32 or SysWow64, or any other system directory unless they're never going to change or very infrequently.

roger levy
Member #2,513
July 2002

I seem to recall it being possible to compile all the dependencies into the allegro DLL. I think I did this to clean up the install directory of The Lady, a few years back. Would it be easy for you to do? Seriously I would paypal you $20 to avoid having to do it myself.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Uh, I would have to do it manually, and then it would be a static library. I'm not sure that's what you want.

Well, I could probably make it dynamic, but I don't remember the linker incantations to do so. It might take me a while, and I'm not sure why you need it.

roger levy
Member #2,513
July 2002

Two reasons...

The framework I've built (Bubble) is loaded into the IDE, which is an EXE in a different directory. The IDE is the compiler. We load and test application code interactively here, and sometimes spit out an application exe. The issue is that I had to put in a notice telling people to copy all DLL's to the IDE's bin folder if they want sound. Not a show stopper, but it is a weak point; a person can forget to do that when I release the framework with new versions of Allegro.

The other reason is just my sense of tidiness. :P

I leave it totally up to you if you feel like doing it. I wasn't kidding about paying!

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

There's probably some kind of licensing issue when cramming all those libraries into a giant glob like that.

DLL distribution is nothing new. Do you not have the option of static linking? How does the SwiftForth Allegro interface work? Are you loading the DLLs at runtime in your SF program?

Your IDE should have an option to select the current working directory. That is where the DLLs should be located.

roger levy
Member #2,513
July 2002

Newp, no static linking, though in theory it could be done, at that point you're replicating GNU, haha.

I think the SwiftForth FFI just saves the Forth CPU state, creates a stack frame and calls DLL functions and then reverses the process to come back to Forth. Pretty straightforward. I do not have to load any dependencies of Allegro manually, I believe it is automatically done by Allegro's behind-the-scenes C stuff when I initialize. I just declare Allegro and SwiftForth takes care of loading it, in a similar fashion to C.

By "select the current working directory", what do you mean exactly? Like chdir? Or is there something else, like a WINAPI function I should call?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Yes, the following code will allow you to set the current working directory to the directory the executable is in. Use al_change_directory instead of _chdir or chdir. It takes care of the cross platform stuff for you.

Untested... but I've done this before so it's got to be close

/** #include "direct.h" */
//...

ALLEGRO_PATH* p = al_get_standard_path(ALLEGRO_EXENAME_PATH);

al_set_path_filename(p , NULL);

/** _chdir(al_path_cstr(p));*/

al_change_directory(al_path_cstr(p));

al_destroy_path(p);

p = 0;

roger levy
Member #2,513
July 2002

I will try it but I don't think it solves my problem of having to put the DLL's in SwiftForth's folder instead of being able to just keep them packaged in my framework's libraries subfolder.

 1   2 


Go to: