Winegcc issues with compilation and successive execution.

[llde]

Premise: I'm sorry for the very inexplicative title, but I could not got to a bettter one. There are some different issue I encountered (and some were already bypassed).

I'm a member of a group of two people working on a multiplatform application for a University project. The application must work on Windows and various unixes (we are limiting to POSIX2008 complaint systems as Linux,OSX and {Free,Open}BSD. And possibly Redox OS). However my friend box with Windows started misbeheving (probably for corruption of some disk sector), and we are currently in position of not being able to test anything on Windows. So I thinked to compile the application with winegcc and use wine. (my PC cannot handle a VM win Windows 7 or windows 10).

First trouble: in our sourcecode there are some "preprocessors guards" for platform specific behviour. so the code is full of #ifdef _WIN32 #elif defined(__unix__)
This kind of guard doesnt' give issues, but some guards are needed for unix only. (For example some imports for working with sockets). So I saw that the "__unix__" macro is defined by winegcc.
I worked around this using -U__unix__ parameter to winegcc.

Second issue
Warning undeclared function:
pool.c: In function ‘CreateThreadPool’:
pool.c:185:17: warning: implicit declaration of function ‘snprintf’ [-Wimplicit-
function-declaration]
error = snprintf(kername, newlen, "%s_%d", name, i);
^~~~~~~~
pool.c:185:17: warning: incompatible implicit declaration of built-in function
snprintf’
pool.c:185:17: note: include ‘<stdio.h>’ or provide a declaration of ‘snprintf’
(stdio.h is included. I'm working with -mno-cygwin flag).
Seeing inside wine msvcrt stdio.h is only defined the _snprintf.
However the function seems to link to something.
(I worked around making a guarded #define snprintf _snprintf)

Third and final issue:
After having resolved the compilation errors (Application using winelib can and should use ws2tcpip.h header directly as MSVC instead of importing windows.h as MINGW) and linking the applications , the executables are generated, but doesn't work, crashing with a Segmentation fault.
The CFLAGS is defined as "-U__unix__ -mno-cygwin " plus warnings (note that the code use openmp directives the are ignored without passing -fopenmp. However passing or non passing this flag doesn't change the outcome).
stdout/stderr:
fixme:winediag:start_process Wine Staging 2.18 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
zsh: segmentation fault (core dumped) ./test.exe

thnaks in andvance for the help

[DarkPlayer]

I would suggest you to use mingw to compile your applications. When using winegcc you must be extremely careful as you easily mix up header files of the host system and the win32 api. If you for example manage to include the linux definitions for sockets, but link against the winsock api, the calling convention won't match (cdecl vs. stdcall), leading to crashes. The alignment of double values in structures is also different. So when using the windows api you would need to make sure that you are using DOUBLE as structure field type and double for linux. Another advantage of mingw is that you can also run the compiled applications on windows. Please note that Wine is sometimes less restrict when it comes to parameter validation of functions and there is no guarantee that an application running in Wine will also work on Windows.

[llde]

Followup of the last problem:
I discovered that wineggc or wine misbehave when using the __attribute__(constructor) (and maybe __attribute__(destructor)) gcc specifci extension.

Removing the atributes from the offended functions, the program compile and work (sort of. windows side is still unfinished or unpolished).

Also another little quirk:
In the Winapi the DWORD type is defined as "unsigned long" and it's format specifier for format strings is %lu. However in winelib is defined as "unsigned int" and use %u as format specifier.

@DarkPlayer
It's not the first time I compile something for the winapi with winegcc. I use -mno-cygwin in CFLAGS and all the import for unix specific headers are guarded by #ifdef _unix__ or #ifdef __linux__ macros.
The problem lied in a specific function attribute (constructor and destructor) provided by gcc compiler (is a gcc extension).

Also my distro doesn't have a mingw compiled packages. And they are so many splitted packages I become mad when I tried to understand what going on.