Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2017-09-28 21:44:30
|
Three of the source files in gnuplot's src/win32 use the function swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of these files, wgdiplus.cpp, there's a recognition that this function is not universally available: #ifdef __WATCOMC__ // swprintf_s is missing from <cwchar> # define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__) #endif It seems to me that this guard against use of an undefined function should also be present in wmenu.c and wtext.c. Moreover, it's not just the Watcom compiler that's affected: swprintf_s is not declared in the headers provided for cross-compilation via mingw64. Hence, a request: could this back-up definition be provided in all the affected files, and could it please be extended from __WATCOM__ to some convenient symbol that could be defined on the compiler command line for any system that's missing the definition -- for example something like: #if defined(__WATCOM__) || defined(SWPRINTF_S_MISSING) <alternative definition> #endif That way, one would not have to hack these three files to get current wgnuplot.exe to build. Thanks. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-09-29 13:05:48
|
Am 28.09.2017 um 23:12 schrieb Allin Cottrell: > Three of the source files in gnuplot's src/win32 use the function > swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of these > files, wgdiplus.cpp, there's a recognition that this function is not > universally available: > > #ifdef __WATCOMC__ > // swprintf_s is missing from <cwchar> > # define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__) > #endif > > It seems to me that this guard against use of an undefined function > should also be present in wmenu.c and wtext.c It may seem like that at first glance, but it's not actually the case. OpenWatcom does supply swprintf_s(), but only for C source code, not for C++. I.e. it's in <wchar.h>, but not available via its C++ equivalent, <cwchar>. . Moreover, it's not just > the Watcom compiler that's affected: swprintf_s is not declared in the > headers provided for cross-compilation via mingw64. I see no such problem here. Maybe your version of mingw64 is outdated? (For reference, I'm using the current version of the MinGW64 headers as installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1). |
|
From: Allin C. <cot...@wf...> - 2017-09-29 19:16:53
|
On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote: > Am 28.09.2017 um 23:12 schrieb Allin Cottrell: >> Three of the source files in gnuplot's src/win32 use the function >> swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of these >> files, wgdiplus.cpp, there's a recognition that this function is not >> universally available: >> >> #ifdef __WATCOMC__ >> // swprintf_s is missing from <cwchar> >> # define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__) >> #endif >> >> It seems to me that this guard against use of an undefined function should >> also be present in wmenu.c and wtext.c > > It may seem like that at first glance, but it's not actually the case. > OpenWatcom does supply swprintf_s(), but only for C source code, not for C++. > I.e. it's in <wchar.h>, but not available via its C++ equivalent, <cwchar>. OK, I see. > . Moreover, it's not just >> the Watcom compiler that's affected: swprintf_s is not declared in the >> headers provided for cross-compilation via mingw64. > > I see no such problem here. Maybe your version of mingw64 is outdated? > > (For reference, I'm using the current version of the MinGW64 headers as > installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1). My headers are also version 5.0.2 but I guess something must be wrong with my setup; I'll investigate. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2017-09-29 19:15:15
|
On Fri, 29 Sep 2017, Allin Cottrell wrote: > On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote: > >> Moreover, it's not just >>> the Watcom compiler that's affected: swprintf_s is not declared in the >>> headers provided for cross-compilation via mingw64. >> >> I see no such problem here. Maybe your version of mingw64 is outdated? >> >> (For reference, I'm using the current version of the MinGW64 headers as >> installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1). > > My headers are also version 5.0.2 but I guess something must be > wrong with my setup; I'll investigate. Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe that information could be added in config/mingw? Allin Cottrell |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-09-29 20:23:53
|
Am 29.09.2017 um 21:14 schrieb Allin Cottrell: > On Fri, 29 Sep 2017, Allin Cottrell wrote: >> My headers are also version 5.0.2 but I guess something must be wrong >> with my setup; I'll investigate. > > Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe > that information could be added in config/mingw? No, I don't think it should, since the program builds fine without it. I check with both with the MinGW64 cross tools provided by Cygwin (that's config/cygwin) and with MSYS2 MinGW64 (config/mingw). That switch is supposed to controlled by MinGW's own configuration header, <_mingw.h>. |
|
From: Allin C. <cot...@wf...> - 2017-09-29 20:48:38
|
On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote: > Am 29.09.2017 um 21:14 schrieb Allin Cottrell: >> On Fri, 29 Sep 2017, Allin Cottrell wrote: > >>> My headers are also version 5.0.2 but I guess something must be wrong with >>> my setup; I'll investigate. >> >> Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe that >> information could be added in config/mingw? > > No, I don't think it should, since the program builds fine without it. I > check with both with the MinGW64 cross tools provided by Cygwin (that's > config/cygwin) and with MSYS2 MinGW64 (config/mingw). > > That switch is supposed to controlled by MinGW's own configuration header, > <_mingw.h>. In current mingw64 built from source on Linux (x86_64-w64-mingw32 and i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in _mingw.h, or anywhere else, unless you choose --enable-secure-api at configure time (it's not enabled by default). Most software I've cross-built for Windows doesn't require sec_api so building wgnuplot is the first time I've come across this. I think it should be stated somewhere in config/mingw that you need to enable this (somewhow) to build wgnuplot. No harm done if one is using a pre-built mingw64 which already enables it. Allin Cottrell |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-09-29 21:22:26
|
Am 29.09.2017 um 22:48 schrieb Allin Cottrell: > In current mingw64 built from source on Linux (x86_64-w64-mingw32 and > i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in _mingw.h, or > anywhere else, unless you choose --enable-secure-api at configure time > (it's not enabled by default). Most software I've cross-built for > Windows doesn't require sec_api so building wgnuplot is the first time > I've come across this. Well, suffice it to say that the provided configuration in config/mingw is explicitly designed for MSYS2 MinGW, which doesn't need that switch (and would cause redefinition warnings if it was set). A cross-build from Linux is a completely separate kettle of fish. There would be a lot of other problems with that, starting with the lack of a Linux edition of Microsoft's HTML Help Workshop... |
|
From: Allin C. <cot...@wf...> - 2017-09-29 22:11:54
|
On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote: > Am 29.09.2017 um 22:48 schrieb Allin Cottrell: > >> In current mingw64 built from source on Linux (x86_64-w64-mingw32 and >> i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in _mingw.h, or >> anywhere else, unless you choose --enable-secure-api at configure time >> (it's not enabled by default). Most software I've cross-built for Windows >> doesn't require sec_api so building wgnuplot is the first time I've come >> across this. > > Well, suffice it to say that the provided configuration in config/mingw is > explicitly designed for MSYS2 MinGW, which doesn't need that switch (and > would cause redefinition warnings if it was set). > > A cross-build from Linux is a completely separate kettle of fish. There > would be a lot of other problems with that, starting with the lack of a Linux > edition of Microsoft's HTML Help Workshop... It's easy enough to borrow a copy of wgnuplot.chm from a native Windows build, if one doesn't have the patience to get the HTML Help builder working under wine. Everything else works OK, modulo the MS "secure api" requirement (which is a relatively new thing, it wasn't an issue in years past). All I'm suggesting is something like a note in config/mingw/Makefile saying you need to ensure that your mingw64 header build has enable-secure-api set. That would have saved me a fair amount of frustration. Allin Cottrell |
