compiling : libpng / zlib

16 views
Skip to first unread message

Yves Rizoud

unread,
Apr 8, 2020, 11:16:25 AM4/8/20
to grafx2
Anybody knows which versions of libpng and zlib I need to use so they work together ? Last time I sucessfully compiled everything from source I had zlib 1.2.11 and libpng 1613. I now downloaded the latest libpng 1637, can't even compile it.
In both cases (trying to compile grafx2 or libpng itself) there is a dozen of errors like :
In file included from pngstruct.h:30:0,
                 from pngpriv.h:913,
                 from png.c:14:
d:\grafx2devenv\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/zlib.h:87:5: error: unknown type name 'z_const'

Yves

miniupnp

unread,
Apr 9, 2020, 4:26:15 AM4/9/20
to gra...@googlegroups.com
hello,

What toolchain are you using ?

Gitlab-ci is properly building GrafX2 with MingW32 with zlib1.2.11 and libpng 1.6.37 :
https://gitlab.com/GrafX2/grafX2/-/jobs/496446473

Appveyor is also building int with mingw32 :
https://ci.appveyor.com/project/pulkomandy/grafx2/builds/31911131?fullLog=true

Regarding MS Visual Studio, I think I build on my Windows machine with libpng 1.6.34 and zlib 1.2.11

Regards,

Thomas
--

---
You received this message because you are subscribed to the Google Groups "GrafX2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafx2+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grafx2/CAJfOAy8Vb6YACBd_-BoK8ihPDOGzj7-17vK%2B9V3j2nUqTf-RuA%40mail.gmail.com.

Yves Rizoud

unread,
Apr 9, 2020, 10:17:40 AM4/9/20
to grafx2
Mingw GCC on an Windows XP machine (32bit).
This issue is now solved, it was a conflict between several versions of zlib / png (Why does Mingw use two locations mingw/include and mingw/msys/1.0/include...)
I also had trouble with leftovers in the 3rdparty directory that stay there despite make clean and git reset --hard.

For memory, I have to build with make API=sdl2 SDL2CONFIG=sdl2-config
because otherwise the makefile autodetects SDL2CONFIG as 'empty string', resulting in error messages : make: --cflags: Command not found
I have to fix sdl2-config itself because the official 2.0.12 release has a prefix with a nonsense directory /opt/local/i686-w64-mingw32 (???) An empty prefix makes it produce the correct CFLAGS

The other changes I have to do in order to compile:
 Manually download recoil-5.0.0.tar.gz and 6502-v0.1.tar.xz into 3rdparty/archives. The current hosts are serving files through a HTTPS protocol that is not supported by windows XP.
There seems to be a attempt for recoil on a HTTP mirror (http://nanard.free.fr/grafx2/) but the last version there is 4.3.2

Makefile: 
-$(OBJDIR)/recoil.o:    CFLAGS += -Wno-declaration-after-statement -Wno-unused-parameter
+$(OBJDIR)/recoil.o:    CFLAGS += -Wno-declaration-after-statement -Wno-unused-parameter -std=gnu99
Because GCC 4.6.2 by default chokes on all the for (int i=...;;)

Many files :
Before including <windows.h>, _WIN32_WINNT and/or WINVER has to be set to at least 0x0500 (meaning Windows 2000 and later, such as Windows XP) because Grafx2 references at least the following that need it (there may be more) :
  • CF_DIBV5 (a bitmap header ID)
  • GetLongPathNameW()
  • VK_OEM_COMMA (key ID)
  • AddFontResourceExA()
  • FR_PRIVATE
  • NTM_TT_OPENTYPE
It's a bit tricky because for example shade.c includes keycodes.h and screen.h, which both #include <windows.h> - and the first one that gets included wins.
The cleanest option would have to be a single place that #include <windows.h>, and it is preceded by 
#ifndef WINVER
#define WINVER 0x0500
#endif

With this, the api=SDL2 version compiles and runs
Yves



Yves Rizoud

unread,
Apr 9, 2020, 11:13:19 AM4/9/20
to grafx2
Actually for the latter issue, it is more fool-proof to add -DWINVER=0x0500 to the COPT variable in the makefile :
- In the "ifdef COMSPEC" (compiling on windows is always for windows)
- In the "ifdef WIN32CROSS"

miniupnp

unread,
Apr 9, 2020, 1:19:25 PM4/9/20
to gra...@googlegroups.com
1. I think I need to improve the "make clean" in the 3rdparty directory.

2. about the SDL2CONFIG, the Makefile uses the command
which ../3rdparty/usr-win32/bin/sdl2-config || which sdl2-config
to get it.
I suppose it fails on your system. Do you have a working "which" ?

3. I guess nothing can be done about the new TLS version being not supported under WinXP (which is unsupported for quite a long time now)

Maybe we should document somewhere where to put the .tar.gz

4. I'm a bit surprised by the need for -std=c99, I thought it was included in COPT...

5. what is the default value of _WIN32_WINNT on your toolchain ?
0x0400 is for NT 4 !
0x0500 is for Windows 2000
I'll see how it works when  adding

#ifndef WINVER
#define WINVER 0x0500
#endif

I had started work to reduce the number of files where <windows.h> is included, that should be added there :
https://gitlab.com/GrafX2/grafX2/-/merge_requests/204


regards,

Thomas

miniupnp

unread,
Apr 9, 2020, 2:03:52 PM4/9/20
to gra...@googlegroups.com
Le 09/04/2020 à 17:12, Yves Rizoud a écrit :
Actually for the latter issue, it is more fool-proof to add -DWINVER=0x0500 to the COPT variable in the makefile :
- In the "ifdef COMSPEC" (compiling on windows is always for windows)
- In the "ifdef WIN32CROSS"

indeed.

However, I'm still wondering why this is needed on your system.
On my ming32 install, the file windef.h starts with :


#ifndef WINVER
#define WINVER 0x0500
/*
 * If you need Win32 API features newer the Win95 and WinNT then you must
 * define WINVER before including windows.h or any other method of including
 * the windef.h header.
 */
#endif

#ifndef _WIN32_WINNT
#define _WIN32_WINNT WINVER
/*
 * There may be the need to define _WIN32_WINNT to a value different from
 * the value of WINVER.  I don't have any example of why you would do that.
 * However, if you must then define _WIN32_WINNT to the value required before
 * including windows.h or any other method of including the windef.h header.
 */
#endif

Yves Rizoud

unread,
Apr 9, 2020, 2:59:59 PM4/9/20
to grafx2
I have an older version of the windows headers with Windef.h at 0x0400 by default, which makes it compile executables compatible with Windows 98 ( ~= NT4). For a long time there was no requirement of Windows XP or above, but I think that the support of Unicode affects enough things in Grafx2 to make >= Windows XP mandatory.
I like the COPTS because it ensures all files are compiled with the same version, no matter how many times <windows.h> is included and where.
Setting a specific version has the advantage of being sure which minimum version of OS becomes mandatory (>= Vista, >= 10...)

I don't understand what happens with sdlconfig, make runs every command through bash anyway. I'm trying to troubleshoot it.
Yves





--

---
You received this message because you are subscribed to the Google Groups "GrafX2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafx2+un...@googlegroups.com.

Yves Rizoud

unread,
Apr 10, 2020, 10:06:38 AM4/10/20
to grafx2
Found the issue of sdl2config : A mistyped SDLC2ONFIG on line 127

I'm still not completely sure of the entire management because these variables are set several times, in cases that don't exclude each other.
On my platform with API=sdl2 the variable gets set and the COPT / SDLCOPT flags get assigned at lines 127 and 258


A small note, on GNU bash, the command "which" outputs the following on the standard channel when the command is not found :
which: ../3rdparty/usr-win32/bin/sdl2-config: unknown command
This should probably be suppressed from the makefile output by adding 2> /dev/null
It may still be good to keep it on the last case of the ||, so that the end-user can diagnose that his system finds no sdl-config / sdl2-config.

  SDLCONFIG ?= $(shell which ../3rdparty/usr-win32/bin/sdl-config 2> /dev/null || which sdl-config)
  SDL2CONFIG ?= $(shell which ../3rdparty/usr-win32/bin/sdl2-config 2> /dev/null || which sdl2-config)


Yves


miniupnp

unread,
Apr 11, 2020, 2:33:11 PM4/11/20
to gra...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages