Switched from Linux to Windows, unable to run code

Switched from Linux to Windows, unable to run code

Bob Keane

Member #7,342

June 2006

I switched from Linux to Windows recently and am trying to recompile some code. I set up code::blocks to link Allegro 5.2.4 per the wiki statically and was able to compile and run a program from the tutorial. My program appears to compile properly but when run I get an error stating the libpng16.dll could not be found. The linker settings for my program were copied from the tutorial project. My code was originally written using Allegro 5.2.5 but I don't see how that can make a difference. Any ideas?

By reading this sig, I, the reader, agree to render my soul to Bob Keane. I, the reader, understand this is a legally binding contract and freely render my soul.
"Love thy neighbor as much as you love yourself means be nice to the people next door. Everyone else can go to hell. Missy Cooper.
The advantage to learning something on your own is that there is no one there to tell you something can't be done.

Edgar Reynaldo

Major Reynaldo

May 2007

Either you linked to the dll, or you linked to a library linked to the dll.

Double check your linker settings.

Which binaries did you link to?

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

AceBlkwell

Member #13,038

July 2011

Probably an obvious action but have you searched to confirm the file is actually there and in the location the linker is looking at. I once battled with a similar situation for about 1/2 hour before I realized the file I was needing just wasn’t there. Yeah I know, but sometimes I get focused on what I think the problem is that other possible contributors don’t occur to me. That’s why we have Edgar.

Bob Keane

Member #7,342

June 2006

Edgar, I used the binaries and compiler referenced in this thread:

https://www.allegro.cc/forums/thread/617424

Here is a screen shot of my search directories:

{"name":"612150","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/2\/e214d98e67d46efa996c3b3228116afe.png","w":1366,"h":768,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/2\/e214d98e67d46efa996c3b3228116afe"}

and one of the linker options:

{"name":"612151","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/240973fd3a7c2d6b5af4f8109b6bc078.png","w":1366,"h":768,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/240973fd3a7c2d6b5af4f8109b6bc078"}

AceBlkwell, It is worth looking for the file so I checked the directory. There is a libpng.dll but no libpng16.dll. I don't think that is the problem because I copied a screen program from here, compiled and linked with the same settings and the program runs. The only thing I can think of is my program somehow got corrupted when going from Linux to Windows. Does anyone know the command line options to compile and link? I know I am all over the map on this, but I'll try anything.

bamccaig

Member #7,536

July 2006

If you were able to build it successfully, especially with -lpng16 in your linker settings, then the file exists somewhere. You were able to link with it when your program was linked. You just need to find the file and copy it either somewhere into your PATH, or copy it next to your game. There's a good chance your game will be looking for all of the DLLs so take a look at your linker settings (all of the -lsomething stuff), and when you find libpng16.dll you will likely find all of them nearby. Copy them all into the same folder as your game and see if that works.

You can find it from the command line like this:

dir /a /b /s C:\libpng16.dll 2>NUL

(That will take a long time, depending on how many files are on your C: so go grab a coffee or a beer while it does its thing...)

That will list the full path to any libpng16.dll files on your computer (that you have access to). The 2>NUL will ignore errors (i.e., folders you don't have permission to read), but if you come up empty you can try without to see what errors you're getting. That might give you a clue if it doesn't work.

Based on your IDE settings, I'm thinking you'll find the DLLs in "C:\Users\abk45\OneDrive\Documents\Allegro\Allegro524_mingw-w64-gcc81_posix_dwarf\Allegro524_mingw-w64-gcc81_posix_dwarf\lib" or thereabouts.

--
I mean the best with what I say. It doesn't always sound that way.

Bob Keane

Member #7,342

June 2006

I found the files in the directory you mentioned BamBam and copied them to the source directory and the directory where the executable was and no luck. I then tried deleting the project, recreating and restoring the sources from backup, no luck. My only option looks like deleting the project, recreating and rekeying my code.Urgh.

AceBlkwell

Member #13,038

July 2011

I’m not sure it’s relevant to Allegro 5.x but with Allegro 4 I got a lot of linker errors and”can’t find xxxxx”. I found out I needed alleg42.dll in my source code directory. This may not solve your issue but may trigger an idea you hadn’t thought of to this point. Good luck

bamccaig

Member #7,536

July 2006

First of all, let's not delete anything! Even if that project is fucked, it doesn't hurt to keep it around. And there's always the possibility that it just requires a simple fix.

Is the program something that you can share with something? You could share either the code or the compiled binaries (all of the ones you can think of) and maybe somebody will be able to figure out the problem for you.

Certainly retyping everything would be absurd. This sort of problem is not caused by your code, but by the runtime environment. The files available on the computer.

--
I mean the best with what I say. It doesn't always sound that way.

Edgar Reynaldo

Major Reynaldo

May 2007

FFS Bob, can't I sleep through one day without you deleting your source code?

Try the binaries from here :

https://bitbucket.org/bugsquasher/unofficial-allegro-5-binaries/downloads/Allegro525_GCC81_MinGW_W64_i686_posix_dwarf.7z

They are compatible with the compiler you're using (assuming you're using MinGW-W64 GCC 8.1 Posix Dwarf....)...

Also, the previous version may have had an unwitting dependency. I was still perfecting my build process.

FFS, don't delete anything. >:(

They come with a runtime and build environment.

%A5INCDIR%, %A5LNKDIR%, and %A5STATICLIBS% are all provided to you by the .bat runtime script. And the static dependencies are listed completely in the relevant text file.

Bob Keane

Member #7,342

June 2006

Edgar, First of all, thanks for the help and concern. I deleted my previous binaries and downloaded and installed the ones you suggested. I only unzipped the files, is there any special setup I should do before using them?I checked my gcc compiler, it is gcc 8.1.0 (i686-posix-dwarf-rev0). I checked my compiler and linker setting and was able to compile and run the tutorial program with no problems. I tried my code but get an "undefined reference to WebPGetFeaturesInternal" error. Deleting my code and rekeying it is not a big problem since I have it backed up. I am curious as to why the tutorial works but my code does not.

<edit> I followed the wiki to set up Code::Blocks but it may be out of date. Kere is a list of files I linked with:

#SelectExpand
  1-lallegro_monolith-debug-static
  2-ljpeg 
  3-ldumb 
  4-lFLAC 
  5-lfreetype 
  6-lvorbisfile 
  7-lvorbis 
  8-logg 
  9-lphysfs 
 10-lpng16 
 11-lzlibstatic 
 12-ldsound
 13-lgdiplus 
 14-luuid 
 15-lkernel32 
 16-lwinmm 
 17-lpsapi 
 18-lopengl32 
 19-lglu32 
 20-luser32 
 21-lcomdlg32 
 22-lgdi32 
 23-lshell32 
 24-lole32 
 25-ladvapi32 
 26-lws2_32 
 27-lshlwapi 
 28-static-libstdc++ 
 29-static-libgcc

Am I missing anything?

AceBlkwell

Member #13,038

July 2011

Bob, I'm far from a coding guru and maybe more distracting than help at this point but I can witness to the fact that your code should work both in Linux and Windows. I'm running a dual boot with Slackware and Windows 7. My code, using Allegro 4, works same on both. Meaning the code itself not the IDE of course. Unless you are using some sort of OS specific commands, I think it's a setup issue. Just my 2 cents.

FYI, running Eclipse Neon with GNU for Linux. and portable DevC++ with MinGW64 for Windows.

Good Luck

I was going to share a Allegro 4 static link list of files then realized it wouldn't matter for Allegro 5. But something did occur to me, could you be having a 32 Vs 64 bit conflict? Say compiling at 64 using 32 bit Allegro files? Maybe you need 32 bit MinGW files? Or is there even such a problem?

Edgar Reynaldo

Major Reynaldo

May 2007

Bob, add in -lwebp after allegro. I forgot to add it to the list.

Bob Keane

Member #7,342

June 2006

It worked Edgar. Thanks.

Edgar Reynaldo

Major Reynaldo

May 2007

You'll also want to add in -lpthread near the bottom somewhere. Otherwise you'll get a dependency on the pthread dll.

The full list is now (for my binary package) :

-static 
-lallegro_monolith-debug-static
-ljpeg 
-ldumb
-lwebp
-lFLAC 
-ltheora
-lvorbisfile 
-lvorbis 
-logg 
-lphysfs 
-lfreetype 
-lpng16 
-lzlibstatic 
-ldsound
-lgdiplus 
-luuid 
-lkernel32 
-lwinmm 
-lpsapi 
-lopengl32 
-lglu32 
-luser32 
-lcomdlg32 
-lgdi32 
-lshell32 
-lole32 
-ladvapi32 
-lws2_32 
-lshlwapi 
-lpthread
-static-libstdc++ 
-static-libgcc

Bob Keane

Member #7,342

June 2006

I was able to compile without pthreads but added it in case I need it later. Is it really necessary?

Edgar Reynaldo

Major Reynaldo

May 2007

Do you doubt me? >:(

Yes, most likely you didn't notice because mingw/bin is on your PATH and the pthreads dll is in there.

To test your static exe, enter the following at a command prompt :

cd /d c:\game_directory
cmd
set path=""
game.exe
exit

If your game runs without barfing, that means you did it right.

bamccaig

Member #7,536

July 2006

Just to nitpick, set path="" is technically wrong, though for these purposes it'll work fine. You really just want set PATH= (which unsets the PATH variable). cmd.exe doesn't really handle quotes properly. It's difficult to predict what that would set path to, but I imagine something like a double-quote or maybe two (in Wine, it did set it to two; I cannot test on my work Windows laptop because my cat is digesting on it and I don't want to disturb him). If you do want to quote a variable's value then what works is actually wrapping the name and value in quotes instead: set "PATH=" would work properly too. Case technically doesn't matter in Windows either, but it does on other systems so might as well imagine environment variables to be upper-case. Setting the value to two double-quotes will still work to test your static binary, but it's probably not what you intended.

--
I mean the best with what I say. It doesn't always sound that way.

Edgar Reynaldo

Major Reynaldo

May 2007

Well what do ya know. bambams right. :/

bamccaig

Member #7,536

July 2006

Happens more often than you'd like to admit. :-*

--
I mean the best with what I say. It doesn't always sound that way.