On Mon, Jan 19, 2015 at 12:41 PM, Peter Eisentraut wrote:
> I have committed my mingw portion, but I cannot take on the MSVC part.
OK, no problem. Perhaps I should add a new entry in the next CF for
the MSVC portion?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On 1/15/15 2:37 AM, Michael Paquier wrote:
> On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier
> wrote:
>> Attached are two patches, one for MinGW/cygwin, a slightly modified
>> version from Peter and the second implementing the same thing but for
>> the MSVC scripts. The method for MSVC is similar
On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier
wrote:
> Attached are two patches, one for MinGW/cygwin, a slightly modified
> version from Peter and the second implementing the same thing but for
> the MSVC scripts. The method for MSVC is similar to what is done in
> Peter's patch: roughly it ch
On Mon, Dec 22, 2014 at 2:05 PM, Michael Paquier
wrote:
> Peter, could it be possible to merge this patch with its MSVC portion
> for simplicity? I think that it would more readable to do all the
> changes at the same time once and for all. Also, that's still a bug,
> so are we still considering a
On Wed, Feb 26, 2014 at 6:11 AM, Peter Eisentraut wrote:
> On 2/1/14, 3:22 PM, Andrew Dunstan wrote:
>> In the end I went with the way I had suggested, because that's what the
>> MSVC system does - it doesn't copy any other DLLs to the bin directory.
>> So doing that seemed sane for backpatching,
On 2/1/14, 3:22 PM, Andrew Dunstan wrote:
> In the end I went with the way I had suggested, because that's what the
> MSVC system does - it doesn't copy any other DLLs to the bin directory.
> So doing that seemed sane for backpatching, to bring the two build
> systems into sync.
>
> If you want to
On 02/01/2014 08:01 AM, Peter Eisentraut wrote:
On 1/31/14, 12:47 PM, Andrew Dunstan wrote:
Hmm, looks like it got dropped. I think my original patch is probably
about the the right thing to do, and given that it's already done by
the MSVC build it's a bug and should be backported, as Alvaro s
On 1/31/14, 12:47 PM, Andrew Dunstan wrote:
> Hmm, looks like it got dropped. I think my original patch is probably
> about the the right thing to do, and given that it's already done by
> the MSVC build it's a bug and should be backported, as Alvaro said in
> the original discussion.
>
> I'll ge
On 01/31/2014 12:25 PM, Bruce Momjian wrote:
On Thu, Jul 25, 2013 at 04:53:45PM -0400, Andrew Dunstan wrote:
Jeff Janes asked me about this, and Bruce just tripped up on it.
Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
in the PATH or in the same directory as client .exe f
On Thu, Jul 25, 2013 at 04:53:45PM -0400, Andrew Dunstan wrote:
> Jeff Janes asked me about this, and Bruce just tripped up on it.
> Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
> in the PATH or in the same directory as client .exe files. The
> buildfarm client has for many
From: "Andrew Dunstan"
I don't have a problem adding them to the bin directory. I'd be very
slightly wary of removing them from the lib directory, for legacy reasons.
Maybe these changes should be done for git tip and not backported (or
maybe just to 9.3). Or we could just decide to clean this
On 2013-07-28 15:37:49 -0400, Andrew Dunstan wrote:
> >BTW, why is libpq.dll in lib necessary? For the above files? If so, we
> >can remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it?
>
> Not sure. Perhaps you could experiment and see if anything bad happens if
> libpq is just instal
On 07/25/2013 06:27 PM, MauMau wrote:
From: "Andrew Dunstan"
on Windows it's necessary to have libpq.dll/cygpq.dll either in the PATH
or in the same directory as client .exe files. The buildfarm client has
for many years simply copied this dll from the installation lib to the
installation bin
Il 7/25/2013 11:02 PM, Alvaro Herrera ha scritto:
Andrew Dunstan wrote:
Jeff Janes asked me about this, and Bruce just tripped up on it.
Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
in the PATH or in the same directory as client .exe files. The
buildfarm client has for ma
From: "Andrew Dunstan"
on Windows it's necessary to have libpq.dll/cygpq.dll either in the PATH
or in the same directory as client .exe files. The buildfarm client has
for many years simply copied this dll from the installation lib to the
installation bin directory after running "make install".
Andrew Dunstan wrote:
>
> On 07/25/2013 05:02 PM, Alvaro Herrera wrote:
> >Andrew Dunstan wrote:
> >>Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
> >>in the PATH or in the same directory as client .exe files.
> >
> >Seems a reasonable workaround for a silly platform bug.
On 07/25/2013 05:02 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
Jeff Janes asked me about this, and Bruce just tripped up on it.
Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
in the PATH or in the same directory as client .exe files. The
buildfarm client has for many
Andrew Dunstan wrote:
> Jeff Janes asked me about this, and Bruce just tripped up on it.
> Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
> in the PATH or in the same directory as client .exe files. The
> buildfarm client has for many years simply copied this dll from the
> in
Jeff Janes asked me about this, and Bruce just tripped up on it. Usually
on Windows it's necessary to have libpq.dll/cygpq.dll either in the PATH
or in the same directory as client .exe files. The buildfarm client has
for many years simply copied this dll from the installation lib to the
instal
19 matches
Mail list logo
