Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » MinGW (Windows) Static Linking

This thread is locked; no one can reply to it. rss feed Print
MinGW (Windows) Static Linking
ZoriaRPG
Member #16,714
July 2017
avatar

What is the precise procedure for static linking using MinGW on Windows, and do I need to pass flags to CMake or to MinGW32-make ?

Edgar Reynaldo
Member #8,592
May 2007
avatar

#SelectExpand
1 2-static 3-lalleggl 4-ljpgalleg 5-lloadpng 6-llogg 7-lalleg-debug-static 8-lvorbis 9-lvorbisenc 10-lvorbisfile 11-logg 12-lpng16 13-lzlibstatic 14 15-lkernel32 16-luser32 17-lgdi32 18-lcomdlg32 19-lole32 20-ldinput 21-lddraw 22-ldxguid 23-lwinmm 24-ldsound 25 26-static-libstdc++ 27-static-libgcc

ZoriaRPG
Member #16,714
July 2017
avatar

Do I pass that to the compiler when running make as linker flags; or do I edit the cmake list files, or the cmake config; or are those all args for the cmake CLI programme in the MinGW shell? I thought that the static setup was all cmake options, but I'm not sure at this point.

Those look like flags for cmake, to me.

Here is my CMakeCache file:
https://pastebin.com/bEHWhVcU

Here is the generated makefile:
https://pastebin.com/f2MEjEST

This fails to build, with this error:

24% Linking C static library lib\liballeg.a
C:\MinGW\bin\ar.exe : two different operation options specified
CMakeFiles\allegro.dir\build.make:3568: Recipe for target 'lib\liballeg.a' failed.
MinGW-make[2]: *** [lib\liballeg.a] Error 1
CMakeFiles\Makefile2:66 : Recipe for target 'CMakeFiles/allegro.dir/all' failed.
MinGW-32-make[1]: *** [CMakeFiles/allegro.dir/all] Error 2
Makefile:126 : recipe for target 'all' failed.
MinGW32-make: *** [all] failed.

Perhaps you can have a peek at the CMake config or the makefile and illustrate where I am botching this.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Okay, so you're trying to compile Allegro. I thought you were trying to compile an allegro program using allegro.

For compiling the Allegro 4.4.3 library, you need to specify whether SHARED is on or off (its under ungrouped entries), you need to specify CMAKE_BUILD_TYPE (under CMAKE), which should be Debug or Release, and you need to specify "-static-libstdc++ -static-libgcc" at the end of the CMAKE_C_STANDARD_LIBRARIES variable.

You'll also want to specify CMAKE_INSTALL_PREFIX. When you static link the allegro library, you also need to make sure the static versions of all the dependencies are linked as well, otherwise the resulting allegro library will depend on dlls.

Please list the steps you have taken so far and then I can help you finish. A screenshot of cmake-gui options might be helpful to show you what I mean :
{"name":"611011","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/d\/8dc68baa4c890ddf2ed2de22ad69fab5.png","w":1920,"h":764,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/d\/8dc68baa4c890ddf2ed2de22ad69fab5"}611011

ZoriaRPG
Member #16,714
July 2017
avatar

To clarify what I need, is an allegro 4.4.3 DLL, where all of the deps are static linked. THus, libjpg, libpng, zlib, libogg, and so forth, all statically bound to alleg44.dll, rather than as separate dlls (each).

This is what ZC expects and requires. ::sigh::

I'm not entirely sure why we don't just use a set of DLLs.

I installed the deps following the guide. I did not build them manually. Do I need to manually build the deps (zlib, jpg, png and so forth) in a special way to ensure that I can properly static link them all?

Here is my current CMake Cache
https://pastebin.com/Kv32g0ic

You can see my config options by dropping that file into an allegro path in place of the stock CMakeCache.txt file, (e.g. C:\allegro\CMakeCache.txt) and view all of my config options. If you do that, and you see a problem, you can edit it in the GUI if that is how you roll, and then just post a revised CMakeCache.txt file.

Here is the revised makefile:
https://pastebin.com/4pBCGqyQ

My earlier issues were because I set all of those flags that you posted as LINKER FLAGS for Release Builds.

Now, instead, gcc does not like the png lib, and it is finding a hell of a lot of undefined refs in the object file.

Error Log:
https://pastebin.com/Q0BfxDf3

I'm trying a different .a file for the PNG support, and I will follow up soon with some screenshots.

What file do I want to use for PNG_LIBRARY_RELEASE on Windows, and are the files in your Binaries thread usable on Windows, or only on Linux?

I have tried numerous *png.a libs, including the ones that we used under ZC, the ones that I built, and the ones in your package, and all of them error out.

<img src="I installed the deps following the guide. I did not build them manually. Do I need to manually build the deps (zlib, jpg, png and so forth) in a special way to ensure that I can properly static link them all?

Here is my current CMake Cache
https://pastebin.com/Kv32g0ic

You can see my config options by dropping that file into an allegro path in place of the stock CMakeCache.txt file, (e.g. C:\allegro\CMakeCache.txt) and view all of my congif options. If you do that, and you see a problem, you can edit it in the GUI if that is how you roll, and then just post a revised CMakeCache.txt file.

Here is the revised makefile:
https://pastebin.com/4pBCGqyQ

My earlier issues were because I set all of those flags that you posted as LINKER FLAGS for Release Builds.

Now, instead, gcc does not like the png lib, and it is finding a hell of a lot of undefined refs in the object file.

Error Log:
https://pastebin.com/Q0BfxDf3

I'm trying a different .a file for the PNG support, and I will follow up soon with some screenshots.

<b> What file do I want to use for PNG_LIBRARY_RELEASE on Windows, and are the .a library files in your Binaries thread usable on Windows, or only on Linux?

I have tried numerous *png.a libs, including the ones that we used under ZC, the ones that I built, and the ones in your package, and all of them error out.

{"name":"allegro_cmake_png.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/a\/1a2e619c0bc573579bb5735cce84c316.png","w":960,"h":328,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/a\/1a2e619c0bc573579bb5735cce84c316"}allegro_cmake_png.png

With this configuration, I now have this error on building:

C:\allegro\addons\loadpng\loadpng.c: In function 'really_load_png':
C:\allegro\addons\loadpng\loadpng.c:97:9: warning: variable 'tRNS_to_alpha' set but not used [-Wunused-but-set-variable]
int tRNS_to_alpha = FALSE;
^
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../..\libpng.a(pngrutil.c.obj):pngrutil.c:(.text+0x73d): undefined reference to `inflateReset2'
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../..\libpng.a(pngrutil.c.obj):pngrutil.c:(.text+0x7b0): undefined reference to `inflateValidate'
collect2.exe: error: ld returned 1 exit status
MinGW32-make[2]: *** [addons/loadpng/examples/example.exe] Error 1
MinGW32-make[1]: *** [addons/loadpng/CMakeFiles/example_png.dir/all] Error 2
MinGW32-make: *** [all] Error 2

Edgar Reynaldo
Member #8,592
May 2007
avatar

ZoriaRPG said:

To clarify what I need, is an allegro 4.4.3 DLL, where all of the deps are static linked. THus, libjpg, libpng, zlib, libogg, and so forth, all statically bound to alleg44.dll, rather than as separate dlls (each).

This is what ZC expects and requires. ::sigh::

I'm not entirely sure why we don't just use a set of DLLs.

That's not a good practice. When you link statically, you link everything statically. Likewise, when you link dynamically, you link everything dynamically. If you mix the two you're bound to have problems with redefinition errors sooner or later.

ZC needs to adapt. Allegro 4.4.3 is totally unsupported at this point, and there are few people you'll find who are willing to spend the time to make changes at this point.

You should just static link everything. It's so much easier in the end.

ZoriaRPG said:

What file do I want to use for PNG_LIBRARY_RELEASE on Windows, and are the files in your Binaries thread usable on Windows, or only on Linux?

You have to use a libpng that was compiled with the same compiler you're using to build allegro. That's the way it works. Otherwise you run into all kinds of compatibility errors.

First of all, what compiler are you using and where did you get it from?

ZoriaRPG said:

I have tried numerous *png.a libs, including the ones that we used under ZC, the ones that I built, and the ones in your package, and all of them error out.

allegro_cmake_png.png

With this configuration, I now have this error on building:

Set the include folder to your compiler's include directory. Set the PNG_LIBRARY_RELEASE variable to compiler/lib/libpng16.a .

ZoriaRPG
Member #16,714
July 2017
avatar

It turned out that I was essentially trying to work out a bug that was caused by an effectively undocumented change in AG4's packfile_password() calls.

Under AG4.2 and earlier, the password was set to an empty string after a call to read it. THis changed at some point, and the programme was trying to decrypt the PNG images, or to encrypt them on output.

It was not a linking issue, as I had originally suspected, and I was static linking the deps to the allegro dll in MSVC, properly. The symptom appeared only after we shifted from 4,4.2 to 4.4.3, which is why I thought that it was a library problem.

Reall though Edgar, have you looked at the codebase that we need to update? We have a total of four people working on it, with the following priorities:

1. Release a final, stable 2.50.x series build.
2. Refactor the game engine elements, and incorporate user-end changes to the API.
3. Release incremental support releases, with small feature additions.
4. Release a major version, with the new content, and improved backward compatibility support.
5. Refactor drawing, and audio, to permit changing to another library set.

Our indexed palette system needs to be wholly rewritten, as do all of our map structs, just to support that kind f change; and somehow we would need to maintain full backward compatibility with hundreds of quest files produced from a dozen versions of the programme since 2000.

In the interim, the a4a5 thing might be something that we put time into.

Go to: