Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I think a simple approach is all we need for now - not even sure we
>> need an ifeq() section in the makefile.
>>
>> Here's a patch, which I'll apply unless there's an objection.
> Seems a reasonable step for now, yeah - we ca
Magnus Hagander wrote:
Here's a patch, which I'll apply unless there's an objection.
Seems a reasonable step for now, yeah - we can add BUILDING_LIBPQ
sometime in the future if we need it.
However, you patch needs to set the define in the MSVC build as well,
to make sure that the produ
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> > Tom Lane wrote:
> >
> >> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>
> >>> Shouldn't be too hard to do, but I keep thinking it'd be cleaner
> >>> to just not do the redefine when building libpq. It means we'd
> >>> add a define l
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Shouldn't be too hard to do, but I keep thinking it'd be cleaner to
just not do the redefine when building libpq. It means we'd add a
define like BUILDING_LIBPQ or something to the libpq Makefile, and
e
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Shouldn't be too hard to do, but I keep thinking it'd be cleaner to
> > just not do the redefine when building libpq. It means we'd add a
> > define like BUILDING_LIBPQ or something to the libpq Makefile, and
> > exclude the redefine
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Shouldn't be too hard to do, but I keep thinking it'd be cleaner to
> just not do the redefine when building libpq. It means we'd add a
> define like BUILDING_LIBPQ or something to the libpq Makefile, and
> exclude the redefine if set.
+1 for that gen
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Is there not a (3) which has it included in all frontend code
> > *except* libpq? Do we have a define to do that off?
>
> Offhand I can't think of one.
>
> > In libpq, it's only used in one place to check if a file is present,
> >
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I would be quite happy with that, but before we go down that path
> > I'd like to know why the MSVC builds aren't failing now from this
> > when the MinGW builds are.
>
> Maybe the MSVC linker is willing to bind libpq's call to a saf
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I would be quite happy with that, but before we go down that path I'd
> like to know why the MSVC builds aren't failing now from this when the
> MinGW builds are.
Maybe the MSVC linker is willing to bind libpq's call to a safestat copy
extracted from
Tom Lane wrote:
In libpq, it's only used in one place to check if a file is present,
and one then in the SSL code to determine permissions and such (which
means it's being ignored on win32).
Maybe we could finess the problem by tweaking libpq to not use stat()
at all on Windows.
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Is there not a (3) which has it included in all frontend code *except*
> libpq? Do we have a define to do that off?
Offhand I can't think of one.
> In libpq, it's only used in one place to check if a file is present,
> and one then in the SSL code to
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Cygwin is now building happily, but MinGW is now broken on libpq.
> > It looks like libpq now needs dirmod.o or maybe libpgport.a. What I
> > really don't understand though is why MinGW is broken but MSVC
> > isn't.
>
> I don't think
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom - was there a reason it now runs in FRONTEND as well, or was that
> an oversight?
I did do that intentionally because I was worried about "frontend"
code maybe expecting stat to work fully. Like pg_standby for example.
I think the immediate probl
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm confused about the current state of the pgwin32_safestat stuff.
Me too. I tried to fix it a couple of days ago, but seem to have only
moved the problem around :-(
> Cygwin is now building happily, but MinGW is now broken on libpq. It
> looks lik
Andrew Dunstan wrote:
>
> I'm confused about the current state of the pgwin32_safestat stuff.
> Cygwin is now building happily, but MinGW is now broken on libpq. It
> looks like libpq now needs dirmod.o or maybe libpgport.a. What I
> really don't understand though is why MinGW is broken but MSVC
I'm confused about the current state of the pgwin32_safestat stuff.
Cygwin is now building happily, but MinGW is now broken on libpq. It
looks like libpq now needs dirmod.o or maybe libpgport.a. What I really
don't understand though is why MinGW is broken but MSVC isn't.
cheers
andrew
16 matches
Mail list logo
