[libpq] libpq has a pthread-win32.cpp that conflicts with pthread library on windows

[ankurvdev]

Describe the bug
libpq optionally comes with its own static-implementations of pthread* apis
src\interfaces\libpq\pthread-win32.c (src\interfaces\libpq\Makefile)
that conflicts with libraries that are using pthread port.

This is a problem when linking libpq along with anything else that uses the pthread vcpkg port for pthread functions, using the static windows ports (windows-static )

A clear and concise description of what the bug is.

Environment

• OS: Windows
• Compiler: All

To Reproduce
Reproducing the issue will require setting up a project that links libpq:x64-windows-static (or gdal, osg, osgearth) along with any other port that uses pthreads:x64-windows-static ports.

I believe the fix is to not rely on pthread-win32.c but use pthread port in libpq for pthread* apis.
A good way to test the fix would be to eliminate the pthread-win32.c from libpq port and have the osgearth port compile.
The osgearth port has tool-exe that will fail to link if there are undefined references.

Expected behavior
libpq should use pthread vcpkg port for linking

Failure logs
-(please attached failure logs)

Additional context
Add any other context about the problem here.

[JackBoosY]

Since the upstream doesn't provide a method to use the external pthreads, I think we can only avoid to install both libpq[pthread] and pthreads?

Edit: I think I can patch the source file, but since the upstream won't approve it, my changes will not be accepted in vcpkg.

[Neumann-A]

I think the trick is to mangle the pthread symbols on windows. The pthread-win32 looks more like a mockup than a real pthread implementation.

[ankurvdev]

I'm pretty sure, omitting pthread-win32 from libpq and linking with the pthread port should work.
I can't think of a valid reason why upstream won't accept such a change

[JackBoosY]

@ankurverma85 Can you please report this to the upstream first?