[PATCH] Allow use of <direct.h> from Microsoft Windows to fix mkdir() parameters
This is an alternative to a patch by Esben Haabendal, titled "Fix MinGW builds by adding MKDIR_TAKES_ONE_ARG", posted on Feb 23. Esben's patch made "private.h" optionally include <sys/stat.h> to get at Microsoft's mkdir function, but I think that only works in MinGW, and relies on MinGW's <io.h> header (included by <sys/stat.h>) optionally declaring the mkdir function. The mkdir function is also deprecated by Microsoft. New code should call _mkdir instead. Both functions only take a single parameter. This patch makes "private.h" optionally include <direct.h> (and also <io.h>, due to MinGW's behavior), controlled by the HAVE_DIRECT_H macro, and defines mkdir(path, mode) as macro calling _mkdir(path). With this patch, tz builds successfully in a MSYS2 MingW-w64 Win32 or Win64 environment using the following command line: make CFLAGS="-DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_LINK=0 -DHAVE_SYMLINK=0 -DHAVE_LOCALTIME_R=0" There are some warnings about 'tzname' being redeclared without dllimport attribute, when compiling zdump.c and localtime.c, but the resulting zdump executable seems to work. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
Ian Abbott wrote:
This patch makes "private.h" optionally include <direct.h> (and also <io.h>, due to MinGW's behavior), controlled by the HAVE_DIRECT_H macro, and defines mkdir(path, mode) as macro calling _mkdir(path).
Thanks, I like this better, but better yet let's put this in zic.c since it's the only file that needs the mkdir substitute.
There are some warnings about 'tzname' being redeclared without dllimport attribute, when compiling zdump.c and localtime.c
We should be able to fix this by not redeclaring tzname. How about the attached patch? I've installed it in the experimental repository on GitHub. It also tries to fix the link/symlink problem you mentioned in your other email. It takes a somewhat more-ambitious approach, in an attempt to fix some longstanding minor glitches on POSIX hosts too, while we're at it.
On 26/02/2016 11:39, Paul Eggert wrote:
Ian Abbott wrote:
This patch makes "private.h" optionally include <direct.h> (and also <io.h>, due to MinGW's behavior), controlled by the HAVE_DIRECT_H macro, and defines mkdir(path, mode) as macro calling _mkdir(path).
Thanks, I like this better, but better yet let's put this in zic.c since it's the only file that needs the mkdir substitute.
There are some warnings about 'tzname' being redeclared without dllimport attribute, when compiling zdump.c and localtime.c
We should be able to fix this by not redeclaring tzname. How about the attached patch? I've installed it in the experimental repository on GitHub. It also tries to fix the link/symlink problem you mentioned in your other email. It takes a somewhat more-ambitious approach, in an attempt to fix some longstanding minor glitches on POSIX hosts too, while we're at it.
It builds in a MinGW-w64 Win32 or Win64 environment with the following command line: make CFLAGS="-DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=0" I still get the warnings about the dllimport attribute on 'tzname'. I suppose that can't be helped since we're using the tzname[] defined in "localtime.c", rather than the one from Microsoft's C runtime library DLL. Here's an extract of the build showing the warnings: cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=0 -c -o zdump.o zdump.c zdump.c:247:15: warning: 'tzname' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] extern char * tzname[]; ^ cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=0 -c -o localtime.o localtime.c localtime.c:181:10: warning: 'tzname' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] char * tzname[2] = { ^ If I make the 'date' executable, there are similar warnings when compiling "date.c" and "strftime.c". -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
On 02/26/2016 06:11 AM, Ian Abbott wrote:
It builds in a MinGW-w64 Win32 or Win64 environment with the following command line:
make CFLAGS="-DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=0"
Thanks, but why is the -DHAVE_POSIX_DECLS=0 argument needed? I was hoping that HAVE_POSIX_DECLS could have the default value under MS-Windows.
I still get the warnings about the dllimport attribute on 'tzname'.
Sorry, I forgot to avoid redefinition of tzname. Fixed in the attached patch, which I've installed on GitHub. This still assumes you're compiling without setting HAVE_POSIX_DECLS, though, so possibly we need further changes.
On 26/02/2016 17:06, Paul Eggert wrote:
On 02/26/2016 06:11 AM, Ian Abbott wrote:
It builds in a MinGW-w64 Win32 or Win64 environment with the following command line:
make CFLAGS="-DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=0"
Thanks, but why is the -DHAVE_POSIX_DECLS=0 argument needed? I was hoping that HAVE_POSIX_DECLS could have the default value under MS-Windows.
With -DHAVE_POSIX_DECLS=1, there were more warnings when compiling "localtime.c": cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -DHAVE_SYS_WAIT_H=0 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_DIRECT_H=1 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=1 -c -o localtime.o localtime.c localtime.c:181:10: warning: 'tzname' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] char * tzname[2] = { ^ localtime.c: In function 'ctime_r': localtime.c:1703:16: warning: implicit declaration of function 'asctime_r' [-Wimplicit-function-declaration] return tmp ? asctime_r(tmp, buf) : NULL; ^ localtime.c:1703:36: warning: pointer/integer type mismatch in conditional expression return tmp ? asctime_r(tmp, buf) : NULL; ^ And the make failed when linking 'zdump': cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -o zdump -DHAVE_SYS_WAIT_H=0 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_DIRECT_H=1 -DHAVE_LOCALTIME_R=0 -DHAVE_POSIX_DECLS=1 zdump.o localtime.o asctime.o C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(dsvfs00854.o):(.text+0x0): multiple definition of `tzname' localtime.o:localtime.c:(.data+0x0): first defined here collect2.exe: error: ld returned 1 exit status Makefile:416: recipe for target 'zdump' failed make: *** [zdump] Error 1
I still get the warnings about the dllimport attribute on 'tzname'.
Sorry, I forgot to avoid redefinition of tzname. Fixed in the attached patch, which I've installed on GitHub. This still assumes you're compiling without setting HAVE_POSIX_DECLS, though, so possibly we need further changes.
That's better. It builds with -DHAVE_POSIX_DECLS=1 now, but there are still warnings due to the implicit declaration of 'asctime_r' when compiling "localtime.c" (see above for the actual warnings). Those warnings go away if I add '-DHAVE_INCOMPATIBLE_CTIME_R=1' to CFLAGS. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
On 02/26/2016 10:38 AM, Ian Abbott wrote:
That's better. It builds with -DHAVE_POSIX_DECLS=1 now, but there are still warnings due to the implicit declaration of 'asctime_r' when compiling "localtime.c"
OK, thanks, I think we're getting closer. I installed the attached patch, which I hope fixes these warnings.
On 26/02/2016 20:38, Paul Eggert wrote:
On 02/26/2016 10:38 AM, Ian Abbott wrote:
That's better. It builds with -DHAVE_POSIX_DECLS=1 now, but there are still warnings due to the implicit declaration of 'asctime_r' when compiling "localtime.c"
OK, thanks, I think we're getting closer. I installed the attached patch, which I hope fixes these warnings.
I removed -DHAVE_INCOMPATIBLE_CTIME_R=1, and added -DHAVE_DECL_ASCTIME_R=0 and -DHAVE_LOCALTIME_R=0 to CFLAGS, and it builds without warnings. These are the CFLAGS I'm using: CFLAGS="-DHAVE_SYS_WAIT_H=0 -DHAVE_DIRECT_H=1 -DHAVE_SYMLINK=0 -DHAVE_LINK=0 -DHAVE_DECL_ASCTIME_R=0 -DHAVE_LOCALTIME_R=0" The "HAVE_DECL_ASCTIME_R" name seems to break the current naming convention (if there is one) though! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
Ian Abbott wrote:
The "HAVE_DECL_ASCTIME_R" name seems to break the current naming convention (if there is one) though!
Thanks for checking it. The idea is that HAVE_DECL_FOO is 1 if 'foo' is declared in a system .h file, whereas HAVE_FOO is 1 if 'foo' exists in the library as a function. The convention is not perfect, as there is an ambiguity if a function's name begins with 'decl_', but it should be good enough in practice.
participants (2)
-
Ian Abbott -
Paul Eggert