Welcome to the ZDoom Forums!

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?

[quote="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:
[quote="Graf Zahl"]I couldn't satisfactorily prove that it won't break stuff[/quote][/quote]
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.

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:

[quote="Graf Zahl"]I couldn't satisfactorily prove that it won't break stuff[/quote]

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.

[quote="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.[/quote]

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.

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?

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.

Right, zlib. I could fix it but it could be nice if [url=https://github.com/rheit/zdoom/pull/949/files]this pull[/url] was merged...

It appears in the list anyway, thanks to zlib ;)

EDIT: [b]set(BUILD_SHARED_LIBS OFF)[/b] works for me.

EDIT 2: Force pushed the change just in case.

set(BUILD_SHARED_LIBS OFF)

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]
set(BUILD_SHARED_LIBS OFF)
[/code]

?

Fixed in [url=https://github.com/rheit/zdoom/pull/959]this PR[/url]. This change was copied from GME's Mercurial repository, I just replaced ON with OFF.

Can you check if this happens also before [url=https://github.com/rheit/zdoom/commit/e1af7e3f8c36432b2261323310f39584ad149e83]this zdoom commit[/url]? If not, could you bisect and find when it broke?

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	

When compiling fresh, the following linker error is generated:

[code]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 [/code]

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