Linking msys2 Poco for Mingw-w64 forces wmain as an entry point

[sergio-eld]

https://packages.msys2.org/package/mingw-w64-x86_64-poco version 1.10.1-8

Simple program basically without any code will not link with main as an entry point:

CMakeLists.txt

cmake_minimum_required(VERSION 3.14.2 FATAL_ERROR)

project(smtp LANGUAGES C CXX)

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)

find_package(OpenSSL REQUIRED)
find_package(Poco REQUIRED COMPONENTS NetSSL)

add_executable(send_smtp send_smtp.cpp)
target_link_libraries(send_smtp Poco::NetSSL)

send_smtp.cpp

int main()
{
   return 0;
}

SO: https://stackoverflow.com/questions/73477614/undefined-reference-to-wwinmain-when-linking-poconetssl

Apparently Poco::NetSSL links an object/static lib that defines extern wWinMain. This is definetelly a bug.
Linking libraries does not have to impose any requirements on the app's entry point.

[aleks-f]

There is no wWinMain in Poco::NetSSL_OpenSSL. This is an issue for the packager, not us.

[sergio-eld]

@aleks-f I think it is not that simple. The case is, <Poco/Net/SecureSMTPClientSession.h> includes winbase.h publicly at some point.
If you try to compile this code, you will get a compiler error:

#include <Poco/Net/SecureSMTPClientSession.h>

//int main(int, char **argv) {
int wWinMain(int, wchar_t **) {

  return 0;
}

[1/2] Building CXX object CMakeFiles/send_smtp.dir/send_smtp.cpp.obj
FAILED: CMakeFiles/send_smtp.dir/send_smtp.cpp.obj 
C:\msys64\mingw64\bin\c++.exe -DPOCO_ENABLE_CPP11 -DPOCO_ENABLE_CPP14 -DPOCO_OS_FAMILY_WINDOWS -DPOCO_UNBUNDLED -DUNICODE -D_DEBUG -D_UNICODE  -g -municode -std=gnu++14 -MD -MT CMakeFiles/send_smtp.dir/send_smtp.cpp.obj -MF CMakeFiles\send_smtp.dir\send_smtp.cpp.obj.d -o CMakeFiles/send_smtp.dir/send_smtp.cpp.obj -c C:/Users/sergey.kolesnik/dev/repos/DLP/smtp/send_smtp.cpp
C:/Users/sergey.kolesnik/dev/repos/DLP/smtp/send_smtp.cpp:6:5: error: conflicting declaration of C function 'int wWinMain(int, wchar_t**)'
    6 | int wWinMain(int, wchar_t **) {
      |     ^~~~~~~~
In file included from C:/msys64/mingw64/include/windows.h:70,
                 from C:/msys64/mingw64/include/Poco/UnWindows.h:30,
                 from C:/msys64/mingw64/include/Poco/Platform_WIN32.h:22,
                 from C:/msys64/mingw64/include/Poco/Foundation.h:100,
                 from C:/msys64/mingw64/include/Poco/Net/Net.h:23,
                 from C:/msys64/mingw64/include/Poco/Net/NetSSL.h:23,
                 from C:/msys64/mingw64/include/Poco/Net/SecureSMTPClientSession.h:21,
                 from C:/Users/sergey.kolesnik/dev/repos/DLP/smtp/send_smtp.cpp:2:
C:/msys64/mingw64/include/winbase.h:1112:14: note: previous declaration 'int wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)'
 1112 |   int WINAPI wWinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nShowCmd);
      |              ^~~~~~~~
ninja: build stopped: subcommand failed.

Basically, there may be a case, when Poco header, which is cross-platform, includes Windows headers at a public namespace. Including Windows headers for a library user is bad.
The current problem may be caused by a packager, but it is definetelly a symptom of some problems with Poco's code.

[aleks-f]

Which cross-platform header exactly is including windows headers? From what I'm reading above, the header is named Platform_WIN32.h and that is a platform-specific header, only included on Windows:

poco/Foundation/include/Poco/Foundation.h

Lines 99 to 100 in 2b11cb5

	#if defined(_WIN32)
	#include "Poco/Platform_WIN32.h"

Poco is a collection of cross-platform libraries using native OS headers and API directly, while mingw is pretending to be a gcc environment on windows platform; from that difference, the problems like this originate. I have no problem with people trying to make Poco compile with mingw. But think about what you're doing - essentially pretending to be POSIX environment on Windows to a framework that actually knows how to use Windows API directly.

We do not officially support mingw because (1) so far we had no need for it and (2) we do not have a dedicated maintainer for it. We support windows in a different way, and whoever wants mingw to be properly supported can step up and take the ownership of that aspect.