Thread: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles
Hi all, While looking at some SCRAM stuff, I have bumped into bcc32.mak and win32.mak in src/interfaces/libpq. To put it short: those files are not up to date. The code of SCRAM is in the tree for a bit of time now, and should have updated those files to list and clean up objects, but nobody has reported failures in using them. At the minimum, they should be updated. Or perhaps they could just be ripped out? Who uses that on Windows now? Thanks, -- Michael
Michael Paquier <michael.paquier@gmail.com> writes:
> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
> win32.mak in src/interfaces/libpq. To put it short: those files are
> not up to date. The code of SCRAM is in the tree for a bit of time
> now, and should have updated those files to list and clean up objects,
> but nobody has reported failures in using them.
> At the minimum, they should be updated. Or perhaps they could just be
> ripped out? Who uses that on Windows now?
I'm quite sure no developers use them, or have done so for years.
The ostensible point is to support people who are trying to build
just libpq on Windows, for use in applications talking to PG servers
elsewhere. It was reasonable that some users would want to
do that back when we didn't have a credible native port of the server,
but it's been quite some time since that was true.
In short, I think we could rip them out without much push-back.
But maybe I'm missing some remaining use-case.
regards, tom lane
I wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
>> win32.mak in src/interfaces/libpq. To put it short: those files are
>> not up to date. The code of SCRAM is in the tree for a bit of time
>> now, and should have updated those files to list and clean up objects,
>> but nobody has reported failures in using them.
>> At the minimum, they should be updated. Or perhaps they could just be
>> ripped out? Who uses that on Windows now?
> I'm quite sure no developers use them, or have done so for years.
A bit of digging in the git logs says that the last patch that clearly
resulted from user interest in Borland C was ce53791b2 in April 2009.
bcc32.mak has been touched in passing for various other changes since
then, but I'd say the odds that it actually still works are pretty small,
even before this issue.
win32.mak has considerably more recent interest, eg cd9b4f24c.
So we should consider the two cases separately.
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter. The core argument for bcc32.mak,
I think, is that we never did support building the server with Borland C
... but there's no evidence that people are still building libpq with it
either.
regards, tom lane
On 2017-04-07 00:01:01 -0400, Tom Lane wrote: > Still, it's not very clear why we need to cater for building just libpq > rather than the whole distribution, and a user of win32.mak presumably > has the option to do the latter. I think the raison d'etre for that infrastructure primarily comes from the times where windows wasn't supported for server builds? +1 for yanking this out. - Andres
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Still, it's not very clear why we need to cater for building just libpq > rather than the whole distribution, and a user of win32.mak presumably > has the option to do the latter. The core argument for bcc32.mak, > I think, is that we never did support building the server with Borland C > ... but there's no evidence that people are still building libpq with it > either. Indeed. Those recent reports indicate that removing win32.c would be a bad move. So what about nuking bcc32.mak but updating win32.mak? -- Michael VMware vCenter Server www.vmware.com
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote: > On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Still, it's not very clear why we need to cater for building just libpq > > rather than the whole distribution, and a user of win32.mak presumably > > has the option to do the latter. The core argument for bcc32.mak, > > I think, is that we never did support building the server with Borland C > > ... but there's no evidence that people are still building libpq with it > > either. > > Indeed. Those recent reports indicate that removing win32.c would be a > bad move. For me they indicate the contrary, that we're currently not properly maintaining it so that longstanding errors crop up.
Andres Freund <andres@anarazel.de> writes:
> On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
>> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Still, it's not very clear why we need to cater for building just libpq
>>> rather than the whole distribution, and a user of win32.mak presumably
>>> has the option to do the latter.
>> Indeed. Those recent reports indicate that removing win32.c would be a
>> bad move.
> For me they indicate the contrary, that we're currently not properly
> maintaining it so that longstanding errors crop up.
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.
bcc32.mak is in a different category because it's basically the only
solution if you want to build libpq in Borland C. But the lack of
user input suggests that maybe nobody cares about that anymore.
Borland C, per se, has been dead since the 90s according to wikipedia.
There are successor products with different names, none of which I can
recall anybody ever mentioning on the PG lists. I speculate that
people are taking libpq.dll built with MSVC and using it in those
products, if they're using them with PG at all.
regards, tom lane
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- Andres Freund <andres@anarazel.de> writes:
> On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
>> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Still, it's not very clear why we need to cater for building just libpq
>>> rather than the whole distribution, and a user of win32.mak presumably
>>> has the option to do the latter.
>> Indeed. Those recent reports indicate that removing win32.c would be a
>> bad move.
> For me they indicate the contrary, that we're currently not properly
> maintaining it so that longstanding errors crop up.
Is it broken in HEAD only or also in 9.6?
I think whomever uses win32.mak to build is quite unlikely to be tracking HEAD. They would notice at release time. (Since we don't have a buildfarm animal doing it)
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.
Insurmountable, probably not. The big difference is that you don't need *any* dependencies to build a libpq using win32.mak, but you need many of them (to start with, perl...) to build using the built-in one. For people who want to build it, it certainly save a lot more than "a few minutes". For somebody who doesn't have ready scripts it takes a *long* time to set up a build environment to do our regular msvc builds.
I think the question is more, is there any need for people to do that at all, or are those people just going to be using the pre-built binaries anyway? That question I can't say I know the answer to.
bcc32.mak is in a different category because it's basically the only
solution if you want to build libpq in Borland C. But the lack of
user input suggests that maybe nobody cares about that anymore.
I think there's always been even fewer users of bcc32.mak than of the win32.mak one.
Borland C, per se, has been dead since the 90s according to wikipedia.
There are successor products with different names, none of which I can
recall anybody ever mentioning on the PG lists. I speculate that
people are taking libpq.dll built with MSVC and using it in those
products, if they're using them with PG at all.
The compiler is still called bcc (bcc32c to be specific - see https://www.embarcadero.com/free-tools/ccompiler). Apparently it's clang based now. I don't know if our mak file even works with that anymore though, it wouldn't surprise me if it doesn't. But the non-change-of-name could be why we're not seeing questions about it.
FWIW, I've suggested we drop it before, so no objections to that part from me (and if we do, there's some #ifdefs around it in headers as well).
On 04/07/2017 02:00 PM, Magnus Hagander wrote: > On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Yeah. For win32.mak, the key question is whether there is still anybody >> who'd have an insurmountable problem with building the whole distro via >> src/tools/msvc/ rather than just building libpq with win32.mak. Given our >> lack of infrastructure for testing win32.mak, continuing support for it >> seems like quite an expensive proposition from the developer-time >> standpoint. I don't really want to do that if it's only going to save >> somebody an occasional few minutes of build time. > > Insurmountable, probably not. The big difference is that you don't need > *any* dependencies to build a libpq using win32.mak, but you need many of > them (to start with, perl...) to build using the built-in one. For people > who want to build it, it certainly save a lot more than "a few minutes". > For somebody who doesn't have ready scripts it takes a *long* time to set > up a build environment to do our regular msvc builds. > > I think the question is more, is there any need for people to do that at > all, or are those people just going to be using the pre-built binaries > anyway? That question I can't say I know the answer to. It does seem handy, if all you want is libpq. Clearly not many people use it, though. I just tested it. After adding all the missing files to the makefile, I'm getting an error: > .\Release\libpq.dll.manifest : general error c1010070: Failed to load and parse > the manifest. The system cannot find the file specified. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\10\bin\x86\mt. > XE"' : return code '0x1f' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14. > \VC\BIN\nmake.EXE"' : return code '0x2' > Stop. This seems be the same as the 2nd error that was reported back in 2013: https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%3DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com. Despite the failure, it built a libpq.dll file, and it seems to work. I have no idea what the manifest file is. I could easily add the missing files to win32.mak, but unless someone else steps up to the plate and fixes the manifest issue, I don't think we have much choice but remove the it. - Heikki
Heikki Linnakangas <hlinnaka@iki.fi> writes: > I just tested it. After adding all the missing files to the makefile, > I'm getting an error: >> .\Release\libpq.dll.manifest : general error c1010070: Failed to load and parse >> the manifest. The system cannot find the file specified. > This seems be the same as the 2nd error that was reported back in 2013: > https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%3DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com. Well, if it's been broken since (at least) 2013, and we've had only one complaint, then I'd say there are too few potential users to justify the maintenance burden. regards, tom lane
On 04/07/2017 09:58 AM, Tom Lane wrote: >> This seems be the same as the 2nd error that was reported back in 2013: >> https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%3DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com. > Well, if it's been broken since (at least) 2013, and we've had only one > complaint, then I'd say there are too few potential users to justify > the maintenance burden. > > I agree. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2017-04-07 13:00:39 +0200, Magnus Hagander wrote: > Insurmountable, probably not. The big difference is that you don't need > *any* dependencies to build a libpq using win32.mak, but you need many of > them (to start with, perl...) to build using the built-in one. For people > who want to build it, it certainly save a lot more than "a few minutes". > For somebody who doesn't have ready scripts it takes a *long* time to set > up a build environment to do our regular msvc builds. For a useful libpq you actually need a good chunk of dependencies, including openssl. Greetings, Andres Freund
On Fri, Apr 7, 2017 at 4:03 PM, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
On 04/07/2017 09:58 AM, Tom Lane wrote:
>> This seems be the same as the 2nd error that was reported back in 2013:
>> https://www.postgresql.org/message-id/CAJ2% 3DPVQcW8UGNnSy%3DOw% 3DvUK2zpjowTkzUS1B864REa7LOT14 0Q%40mail.gmail.com.
> Well, if it's been broken since (at least) 2013, and we've had only one
> complaint, then I'd say there are too few potential users to justify
> the maintenance burden.
>
>
I agree.
Are these votes for getting rid of both win32.mak and bcc32.mak?
If so, count me in for the same :) Want me to do the honors, as it's my fault they're in there in the first place?
Magnus Hagander <magnus@hagander.net> writes:
> Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
> If so, count me in for the same :) Want me to do the honors, as it's my
> fault they're in there in the first place?
Sure.
regards, tom lane
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Are these votes for getting rid of both win32.mak and bcc32.mak? > > I'm for it. +1. -- Michael
On Mon, Apr 10, 2017 at 2:07 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
> I'm for it.
+1.
PFA a patch that does this. Did I miss something? :)
--
Attachment
Magnus Hagander <magnus@hagander.net> writes:
>>>> Are these votes for getting rid of both win32.mak and bcc32.mak?
> PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef _MSC_VER".
Or maybe rename it to something else --- I'm not sure what, but
I've always found that symbol rather confusing.
Looks good other than that nitpick.
regards, tom lane
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >>>>> Are these votes for getting rid of both win32.mak and bcc32.mak? > >> PFA a patch that does this. Did I miss something? :) > > Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether; > given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by > "#ifdef _MSC_VER". That's here in the patch for people wondering: -#if defined(_MSC_VER) || defined(__BORLANDC__) +#if defined(_MSC_VER)#define WIN32_ONLY_COMPILER#endif +1 for the renaming. > Or maybe rename it to something else --- I'm not sure what, but > I've always found that symbol rather confusing. No complains here as well. Thanks for the patch. -- Michael
On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>>>>> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
>> PFA a patch that does this. Did I miss something? :)
>
> Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
> given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
> "#ifdef _MSC_VER".
That's here in the patch for people wondering:
-#if defined(_MSC_VER) || defined(__BORLANDC__)
+#if defined(_MSC_VER)
#define WIN32_ONLY_COMPILER
#endif
+1 for the renaming.
Ok, since we have two votes for it, I will go ahead and do that (as a separate patch pushed together).'
> Or maybe rename it to something else --- I'm not sure what, but
> I've always found that symbol rather confusing.
No complains here as well. Thanks for the patch.
Thanks.
On Tue, Apr 11, 2017 at 03:14:23PM +0200, Magnus Hagander wrote: > On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier <michael.paquier@gmail.com> > wrote: > > On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > >>>>> Are these votes for getting rid of both win32.mak and bcc32.mak? > > > >> PFA a patch that does this. Did I miss something? :) > > > > Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether; > > given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by > > "#ifdef _MSC_VER". > > That's here in the patch for people wondering: > -#if defined(_MSC_VER) || defined(__BORLANDC__) > +#if defined(_MSC_VER) > #define WIN32_ONLY_COMPILER > #endif > +1 for the renaming. > > > Ok, since we have two votes for it, I will go ahead and do that (as a separate > patch pushed together).' I am fine with removing things, but I do remember one reason the Borland part was kept is that some tool would only work with the Borland-compiled library, not gcc or MSVC, but that was long ago. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes: > I am fine with removing things, but I do remember one reason the Borland > part was kept is that some tool would only work with the > Borland-compiled library, not gcc or MSVC, but that was long ago. Yeah, very long ago. A quick search of our archives shows that the number of mentions of Borland pretty much fell off a cliff after 2009 (excluding the repeated conversations about dropping support, that is). I found one report suggesting that it was already broken in 2012: https://www.postgresql.org/message-id/flat/AD61A3A7C80949178643FE5D2811C35F%40LynnPC It seems pretty safe to say that nobody's using this build method anymore. As best I can tell from perusing the archives, the reason we used to expend a lot of sweat on it was that there was a freely available version of Borland C and none of MSVC. But that stopped being true a long time ago, so there's not much reason to concern ourselves with it anymore. regards, tom lane
On Tue, Apr 11, 2017 at 04:51:03PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > Yeah, very long ago. A quick search of our archives shows that the number > of mentions of Borland pretty much fell off a cliff after 2009 (excluding > the repeated conversations about dropping support, that is). I found one > report suggesting that it was already broken in 2012: > > https://www.postgresql.org/message-id/flat/AD61A3A7C80949178643FE5D2811C35F%40LynnPC > > It seems pretty safe to say that nobody's using this build method > anymore. As best I can tell from perusing the archives, the reason > we used to expend a lot of sweat on it was that there was a freely > available version of Borland C and none of MSVC. But that stopped > being true a long time ago, so there's not much reason to concern > ourselves with it anymore. Agreed, I was just pointing out why it remained so long. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +