Fixes for building bindings on cygwin

[jon-turney]

Follow up to #211

[igor-raits]

I'm not familiar with cygwin stuff so I can't test it. However from first glance looks good.

[mlschroe]

I wonder if the change won't lead to having library references on non-cygwin systems, so maybe we want to do this conditionally. I'll do some testing.

I'm also curious why cygwin needs this and other systems don't.

Thanks for the pull request!

[igor-raits]

@mlschroe well, technically it works by accident...

⋊> /u/l/p/site-packages ldd -r _solv.so                                                                                                                                                                    17:08:15
	linux-vdso.so.1 (0x00007fffc2be9000)
	libsolvext.so.0 => /lib64/libsolvext.so.0 (0x00007f496375b000)
	libsolv.so.0 => /lib64/libsolv.so.0 (0x00007f49636ce000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4963509000)
	librpmio.so.8 => /lib64/librpmio.so.8 (0x00007f49634d6000)
	librpm.so.8 => /lib64/librpm.so.8 (0x00007f496345b000)
	libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f49632f1000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f49632d5000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f49632ac000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f4963299000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4963813000)
	libelf.so.1 => /lib64/libelf.so.1 (0x00007f496327f000)
	libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f4963271000)
	libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f49631d6000)
	liblua-5.3.so => /lib64/liblua-5.3.so (0x00007f4963196000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f4963012000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f4962d38000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f4962d33000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4962d12000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007f4962d0b000)
	libacl.so.1 => /lib64/libacl.so.1 (0x00007f4962cfe000)
	libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f4962b3a000)
	libattr.so.1 => /lib64/libattr.so.1 (0x00007f4962b32000)
undefined symbol: PyExc_SystemError	(./_solv.so)
undefined symbol: PyExc_NotImplementedError	(./_solv.so)
undefined symbol: _Py_NotImplementedStruct	(./_solv.so)
undefined symbol: PyExc_RuntimeError	(./_solv.so)
undefined symbol: PyExc_MemoryError	(./_solv.so)
undefined symbol: PyExc_ValueError	(./_solv.so)
undefined symbol: PyExc_TypeError	(./_solv.so)
undefined symbol: PyExc_IOError	(./_solv.so)
undefined symbol: PyObject_GenericGetAttr	(./_solv.so)
undefined symbol: PyExc_OverflowError	(./_solv.so)
undefined symbol: PyType_Type	(./_solv.so)
undefined symbol: _Py_NoneStruct	(./_solv.so)
undefined symbol: PyExc_ZeroDivisionError	(./_solv.so)
undefined symbol: PyExc_IndexError	(./_solv.so)
undefined symbol: PyExc_AttributeError	(./_solv.so)
undefined symbol: PyExc_StopIteration	(./_solv.so)
undefined symbol: PyExc_SyntaxError	(./_solv.so)
undefined symbol: PyUnicode_FromFormat	(./_solv.so)
undefined symbol: PyList_New	(./_solv.so)
undefined symbol: PyObject_Init	(./_solv.so)
undefined symbol: PyDict_SetItemString	(./_solv.so)
undefined symbol: PyErr_Restore	(./_solv.so)
undefined symbol: PyLong_FromUnsignedLongLong	(./_solv.so)
undefined symbol: PyObject_AsReadBuffer	(./_solv.so)
undefined symbol: PyLong_AsUnsignedLongLong	(./_solv.so)
undefined symbol: PyObject_GetAttrString	(./_solv.so)
undefined symbol: PyEval_CallObjectWithKeywords	(./_solv.so)
undefined symbol: PyImport_AddModule	(./_solv.so)
undefined symbol: PyUnicode_AsUTF8String	(./_solv.so)
undefined symbol: PyLong_FromSize_t	(./_solv.so)
undefined symbol: PyErr_SetString	(./_solv.so)
undefined symbol: PyObject_IsInstance	(./_solv.so)
undefined symbol: PyObject_Malloc	(./_solv.so)
undefined symbol: PyObject_Free	(./_solv.so)
undefined symbol: PyInstanceMethod_New	(./_solv.so)
undefined symbol: PyCapsule_Import	(./_solv.so)
undefined symbol: PyType_Ready	(./_solv.so)
undefined symbol: PyLong_FromLong	(./_solv.so)
undefined symbol: PyLong_FromVoidPtr	(./_solv.so)
undefined symbol: PyErr_Clear	(./_solv.so)
undefined symbol: PyBool_FromLong	(./_solv.so)
undefined symbol: PyList_Append	(./_solv.so)
undefined symbol: PyTuple_New	(./_solv.so)
undefined symbol: PyArg_UnpackTuple	(./_solv.so)
undefined symbol: PyObject_SetAttr	(./_solv.so)
undefined symbol: Py_BuildValue	(./_solv.so)
undefined symbol: PyErr_Occurred	(./_solv.so)
undefined symbol: PyModule_Create2	(./_solv.so)
undefined symbol: PyLong_AsLong	(./_solv.so)
undefined symbol: PyList_SetItem	(./_solv.so)
undefined symbol: PyObject_CallFunctionObjArgs	(./_solv.so)
undefined symbol: PyTuple_SetItem	(./_solv.so)
undefined symbol: PyObject_Size	(./_solv.so)
undefined symbol: PyUnicode_DecodeUTF8	(./_solv.so)
undefined symbol: PyObject_IsTrue	(./_solv.so)
undefined symbol: PyArg_ParseTuple	(./_solv.so)
undefined symbol: PyList_Size	(./_solv.so)
undefined symbol: Py_DecRef	(./_solv.so)
undefined symbol: PyErr_Fetch	(./_solv.so)
undefined symbol: _PyObject_New	(./_solv.so)
undefined symbol: PyUnicode_FromString	(./_solv.so)
undefined symbol: PyModule_AddObject	(./_solv.so)
undefined symbol: PyObject_Call	(./_solv.so)
undefined symbol: PyCapsule_New	(./_solv.so)
undefined symbol: PyCapsule_GetPointer	(./_solv.so)
undefined symbol: PyModule_GetDict	(./_solv.so)
undefined symbol: PyUnicode_Concat	(./_solv.so)
undefined symbol: PyObject_GetAttr	(./_solv.so)
undefined symbol: PyBytes_AsStringAndSize	(./_solv.so)
undefined symbol: PyList_GetItem	(./_solv.so)
undefined symbol: PyErr_WriteUnraisable	(./_solv.so)

[mlschroe]

But that's not an accident. It works, because it is loaded from the library it extends (i.e. as a "plugin"). I'm just wondering why it doesn't work that way in cygwin.

[igor-raits]

This is what I call "by accident".

In any case, I think solution is correct because whatever is built using setuptools with native extension are linked against libpython..

⋊> /u/l/p/site-packages ldd -r _yaml.cpython-37m-x86_64-linux-gnu.so                                                                                                                                       17:16:52
	linux-vdso.so.1 (0x00007ffc94b80000)
	libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007f388dd72000)
	libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0 (0x00007f388d9fa000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f388d9d9000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f388d814000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f388d80f000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f388d80a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f388d684000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f388ddf5000)

[igor-raits]

And since I'm planning to use -Wl,--no-undefined for F30/F31, this patch would fix a problem.

[mlschroe]

Hmm, but all of the perl modules and some of the python modules on my system have those undefined references. So why should libsolv be different?

[jon-turney]

I'm also curious why cygwin needs this and other systems don't.

Because dynamic linkage works differently for PE, specifically the library which provides a symbol is resolved at link time, not by the loader.

[jon-turney]

so maybe we want to do this conditionally.

The discussion didn't seems to reach a conclusion on this. Should I update this PR to make full linkage conditional on Win32?