[MSVC++] Linker error - cannot find gme.lib

[Rachael]

When compiling fresh, the following linker error is generated:

Code: Select all

Severity	Code	Description	Project	File	Line	Suppression State
Error	LNK1181	cannot open input file '..\game-music-emu\gme\Release\gme.lib'	zdoom	B:\build\qzdoom64\src\LINK	1	

Using an old file allows it to link, but I suspect there are problems.

[Edward-san]

Can you check if this happens also before this zdoom commit? If not, could you bisect and find when it broke?

[_mental_]

Fixed in this PR. This change was copied from GME's Mercurial repository, I just replaced ON with OFF.

[Edward-san]

But `option` shouldn't be used, or else it'll appear in the cmake gui list! Does it happen if you use this instead:

Code: Select all

set(BUILD_SHARED_LIBS OFF)

?

[_mental_]

It appears in the list anyway, thanks to zlib

EDIT: set(BUILD_SHARED_LIBS OFF) works for me.

EDIT 2: Force pushed the change just in case.

[Edward-san]

Right, zlib. I could fix it but it could be nice if this pull was merged...

[Graf Zahl]

I haven't merged that because I couldn't satisfactorily prove that it won't break stuff, this report clearly shows that caution is justified.

[Rachael]

Maybe we should launch a branch to test some of these questionable changes, and if it proves that it compiles on all major platforms with no issues (win/linux/mac) and a test build is given to users for a small amount of time (2-3 days) and no major issues are reported (or at the very least they get fixed quickly) - then we can merge them into the master?

[Edward-san]

I haven't merged that because I couldn't satisfactorily prove that it won't break stuff, this report clearly shows that caution is justified.

Erm, but that change has nothing to do with this report. As I said in that pull request, the code inside the `if ( FALSE )` block will never be executed. You can check this by having a look at the cache file and see that no change happened.

[Rachael]

He's not talking about the problem I reported. He's referring to the fact that I reported a problem due to a library upgrade, he's weary of implementing further upgrades as it is. It kind of goes along with "don't fix it if it's not broke" mentality.

[Edward-san]

Of course, but the zlib pull request is not a code upgrade, but adding back parts of code which were left off (still disabled as explained), so I still don't follow this reasoning:

I couldn't satisfactorily prove that it won't break stuff

[_mental_]

Of course, but the zlib pull request is not a code upgrade, but adding back parts of code which were left off (still disabled as explained), so I still don't follow this reasoning:

I couldn't satisfactorily prove that it won't break stuff

I think we should upgrade to the latest zlib 1.2.8 but try to avoid changes in CMake.
Either I can do it and test on Windows and macOS, clean build with internal and external libraries.
Or if you want to do it and test on Linux, I'll check changes on other platforms.

[_mental_]

I would like to update zlib to 1.2.8 (without CMake changes). Tested it on Windows 32-/64-bit clean build and macOS with FORCE_INTERNAL_ZLIB set to YES.
Should I make PR to ZDoom or GZDoom?