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 ?

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.

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"}

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

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.