Jason, I tried to call the appveyor script, but it was looking for a number of Environment variables I did not have. I got through PY_VER=39 and then thought better of it.
Do you think it would be easier to do it this way: * fork psycopg2 * make my own appveyor account that builds the versions I need... Simulate the appveyor environment on my own workstation Wow, what a lot I've forgotten since before manylinux1 - I used to do this for lxml, PyCrypto, and a lot of other packages :). Still, they were all more or less one-offs - I never got as automated as modern DevOps allows these days. On Tue, Oct 5, 2021 at 2:11 PM Jason Erickson <[email protected]> wrote: > Hi Dan, > > Yeah, unfortunately --static-libpq doesn't do what it should anymore. We > should remove that option. > > When building pyscopg2 from source, the binary Windows Postgres packages > does not include the statically linked library (In fairness, I haven't > checked the latest packages, but that is how it has been in the past). The > library included with the binary packages was the DLL import library and it > was named libpq.lib. This is an issue, because originally when you built > from source on windows, the file libpq.lib was the static link library, > whereas the DLL import library was named libpqdll.lib. So we have a name > inconsistency and no way to link statically with the Postgres binary > distribution. > > This got even more convoluted a few major versions back with the source of > Postgres, as the Windows perl build scripts quit creating the build file > for the static link library, only building the DLL import library AND > naming it libpq.lib. With our Appveyor build script, I cheated and > modified the perl script to build the library instead of the DLL at this > line: > file_replace('Mkvcbuild.pm', "'libpq', 'dll'", "'libpq', 'lib'") > > With that said, I am not happy with that solution and always intended to > revisit the setup script portion for windows, but always had more questions > than answers, some of them: > * If static libraries are not part of the Postgres binary distribution (or > even the build from source option by default), do we concern ourselves with > them? Personally I prefer static libraries because I think it has less > support issues, but??? > * If people are building psycopg from source, what libraries do we assume > they have installed? pg_config probably would not be working, so > include/library paths would have to be passed. What about other > dependencies (ie openssl, still use the has_ssl flag?)? There are slightly > different link libraries between some Postgres, so versions matter, too. > * Do we try to differentiate between the DLL import library and the static > library since the name can be the same between them (size?)? > * Or do we say heck with it and just link against a file named libpq.lib, > letting the builder point to the libpq they want to use? > > Maybe an option is to have setup.py on windows call the appveyor script > (with some modifications) and build everything from scratch? It takes > about 40 minutes to build everything, tho, and does require some storage > space for the source and build files, so not the best solution. > > -jason > > > On Mon, Oct 4, 2021 at 5:13 PM Daniele Varrazzo < > [email protected]> wrote: > >> Hi Dan, >> >> On Tue, 5 Oct 2021 at 01:01, Dan Davis <[email protected]> wrote: >> > >> > Can anyone give me a solution to build psycopg2 statically on Windows? >> > >> > I have succeeded in building it, but when I run dumpbin /dependents on >> the generated file (the PYD file), it still depends on libpq.dll even when >> I pass --static-libpq. >> >> I haven't personally used --static-libpq in a long time, and neither >> have I used windows for a while. As far as I know that part of the set >> up might have bitrotten. >> >> If anyone can help Dan it would be appreciated. >> >> Dan, there is a ticket/MR in the tracker of which I've never been able >> to make completely sense: https://github.com/psycopg/psycopg2/pull/758 >> Would you like to check if that's the issue that doesn't allow >> building the lib statically and if so can you propose a MR or just >> acknowledge that the proposed one works as expected? >> >> Thank you everyone >> >> -- Daniele >> >> >>
