Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXouE-0001dO-TV for psycopg@arkaria.postgresql.org; Tue, 05 Oct 2021 18:11:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mXouD-0002JL-L3 for psycopg@arkaria.postgresql.org; Tue, 05 Oct 2021 18:11:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXouD-0002JD-Ba for psycopg@lists.postgresql.org; Tue, 05 Oct 2021 18:11:09 +0000 Received: from mail-vs1-xe2f.google.com ([2607:f8b0:4864:20::e2f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mXou8-0005Fa-N9 for psycopg@lists.postgresql.org; Tue, 05 Oct 2021 18:11:08 +0000 Received: by mail-vs1-xe2f.google.com with SMTP id g10so156197vsb.8 for ; Tue, 05 Oct 2021 11:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stickpeople.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5LexvKGhPcOo+pG9CXuA3t1Zf1yb6e9Idh13WTJJLQ8=; b=ULgdoIR/doaome2Ov9Rt4MzGPuSM9/oMckU3RWSvV5XNU/jKgZQfC8MtkehTMWhCJQ Qk1cCj7/l6o0fodDgKTWYxEDCuOdyZvl6NDGFpG1EoEbHRfcqJj7/1r5JdePkmoa8kiD 3Pj223HGJ7BvKh6bUQgjvyICFYFdfRa9yf88DfaEW9808VBM/EPyWLaWk4b35y9eARw/ 2zYKlSGp3hE0U2UtnYmT4dMAqkHqfP015vyPSJSL654JITJYsojueAxfo0hmjjMPPWy/ 8Ficcn7YTV7T+qM7V7IMxizQ0HwyZG5m8ciS6pLoFP74va/65ui1E4KwT8WJQUo2egNC yArw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5LexvKGhPcOo+pG9CXuA3t1Zf1yb6e9Idh13WTJJLQ8=; b=JMF7Vdf7wqIFnNlAN/Xgixj1GtaiK71JJEDeLqhNl2/F3gO+CVGb0L2ySlTJgsfQTj tyeKIJ+HT+5kkedPbbX0Jic+C6bMljR++/H8NCJ5BDF3mR/WF0ebIJDd5Au7/0HqdFds NhZd5LojygphbMyyUPDsda5jgFVzCxoLi1aCDMMvekP8v8+c+jgxXnOJz6gQcgfRfKaf uDa+qmlEJumcQC4St+o9kOnDvh8ReHwOc4lvZeZv9vDXvipdrD6Z1N/nnrByOuiOmv/N rwlzkXhU42wWfBG61lnfQArc8TgGHdu5uW/8UQsiiXZM/Z4DUcRhpG4gYWHgeUM53ybd +1GQ== X-Gm-Message-State: AOAM531rwzegQM8QFmvg7MDvB/jHnAzh9u2DcnsS6cC52qAQAeX/oyIo kuNFYS0aTpcUuhvZqs6Z0TDLesHsQo+wNT8Wh73Guw== X-Google-Smtp-Source: ABdhPJxT7D6QYWEMphBsQLdamJCwyqMacDeQeRUAS4Ykcmb7ICZL35ulmpjWYRPj3jwTeg5XqKFYORV9HKZzJ7CtSqY= X-Received: by 2002:a67:1c05:: with SMTP id c5mr20352940vsc.25.1633457462188; Tue, 05 Oct 2021 11:11:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jason Erickson Date: Tue, 5 Oct 2021 12:10:51 -0600 Message-ID: Subject: Re: How to build statically on Windows To: Daniele Varrazzo Cc: Dan Davis , psycopg@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000ca2f1805cd9ef323" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ca2f1805cd9ef323 Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hi Dan, > > On Tue, 5 Oct 2021 at 01:01, Dan Davis 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 > > > --000000000000ca2f1805cd9ef323 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dan,

Yeah, unfortunately = --static-libpq doesn't do what it should anymore.=C2=A0 We should remov= e that option.

When building pyscopg2 from source,= the binary Windows Postgres packages does not include the statically linke= d library (In fairness, I haven't checked the latest=C2=A0packages, but= that is how it has been in the past).=C2=A0 The library included with the = binary packages was the DLL import library and it was named libpq.lib.=C2= =A0 This is an issue, because originally when you built from source on wind= ows, the file libpq.lib was the static link library, whereas the DLL import= library was named libpqdll.lib.=C2=A0 So we have a name inconsistency and= =C2=A0no way to link statically with the Postgres binary distribution.
<= /div>

This got even more convoluted a few majo= r versions back with the source of Postgres, as the Windows perl build scri= pts quit creating the build file for the static link library, only building= the DLL import library AND naming it libpq.lib.=C2=A0 With our Appveyor bu= ild script, I cheated and modified the perl script to build the library ins= tead of the DLL at this line:
=C2=A0 =C2=A0 =C2=A0 file_replace('Mkvcbui= ld.pm', "'libpq', 'd= ll'", "'libpq', = 9;lib'")

With that said, I am not = happy with that solution and always intended to revisit the setup script po= rtion for windows, but always had more questions than answers, some of them= :
* If static libraries are not part of the Postgres= =C2=A0binary distribution (or even the build from source option by default)= , do we concern ourselves with them? Personally I prefer static libraries b= ecause I think it has less support issues, but???
* If people= are building psycopg from source, what libraries do we assume they have in= stalled?=C2=A0 pg_config probably would not be working, so include/library = paths would have to be passed. What about other dependencies (ie openssl, s= till use the has_ssl flag?)?=C2=A0 There are slightly different link librar= ies between some Postgres, so versions matter, too.
* Do we t= ry to differentiate between the DLL import library and the static library s= ince the name can be the same between them (size?)?
* Or do we sa= y heck with it and just link against a file named libpq.lib, letting the bu= ilder point to the libpq they want to use?

Maybe a= n option is to have setup.py on windows call the appveyor script (with some= modifications) and build everything from scratch?=C2=A0 It takes about 40 = minutes to build everything, tho, and does require some storage space for t= he source and build files, so not the best solution.

-jason


On Mon, Oct 4, 2021 at 5:13 PM Daniele Varraz= zo <dani= ele.varrazzo@gmail.com> wrote:
Hi Dan,

On Tue, 5 Oct 2021 at 01:01, Dan Davis <dansmood@gmail.com> 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<= br> to make completely sense: https://github.com/psycopg/psy= copg2/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


--000000000000ca2f1805cd9ef323--