Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
which looks very odd indeed, especially:
-L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE
-lperl58
Ah, I see the problem:
ifeq ($(PORTNAME), win32)
perl_archlibexp := $(subst \,/,$(pe
Jim C. Nasby wrote:
Turns out there was a cvs conflict. Doh!
Ouch. I have repeatedly warned buildfarm owners not to make any changes
or run builds in buildfarm's local CVS repo. Use a copy if necessary.
Hmm... would probably be a good idea to have the script check for
conflicts and th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> which looks very odd indeed, especially:
> -L -L../../../src/backend -L../../../src/port -L/c/tcl/lib C:/Perl/lib/CORE
> -lperl58
Ah, I see the problem:
ifeq ($(PORTNAME), win32)
perl_archlibexp := $(subst \,/,$(perl_archlibexp))
perl_privlibexp :
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
This patch seems to have broken builds on Windows and other boxes (e.g.
buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
we find a more robust solution :-(
The only thing I see any evidence for is a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This patch seems to have broken builds on Windows and other boxes (e.g.
> buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
> we find a more robust solution :-(
The only thing I see any evidence for is a broken version of gmake
This patch seems to have broken builds on Windows and other boxes (e.g.
buildfarm's octopus, a FreeBSD box). Maybe this should be reverted until
we find a more robust solution :-(
cheers
andrew
Bruce Momjian wrote:
Patch applied. Thanks.
-
Patch applied. Thanks.
---
Peter Eisentraut wrote:
> I wrote:
> > So either we code up some intelligence to put the "C" in the right
> > position or we have to pass down "A B" and "D" separately from the
> > main makefile
Could we please get this patch applied? It seems like the right thing to do.
cheers
andrew
Jim C. Nasby wrote:
On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote:
I wrote:
So either we code up some intelligence to put the "C" in the right
position or we have to pass d
On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote:
> I wrote:
> > So either we code up some intelligence to put the "C" in the right
> > position or we have to pass down "A B" and "D" separately from the
> > main makefile.
>
> The following patch might just do the former. Please tr
I wrote:
> So either we code up some intelligence to put the "C" in the right
> position or we have to pass down "A B" and "D" separately from the
> main makefile.
The following patch might just do the former. Please try it out.
diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
---
Jim C. Nasby wrote:
> > B: in-tree libraries that we might need (in case of ecpglib: libpq)
> > A: path to those in-tree libraries
>
> Is A even represented in the build at all right now? ISTM it's not,
Sure it is. How else would anything like psql and pg_dump find libpq?
--
Peter Eisentraut
ht
On Mon, Jul 04, 2005 at 05:58:27PM +0200, Peter Eisentraut wrote:
> Andrew Dunstan wrote:
> > I was also slightly dubious about it. However, we do still need to
> > solve the problem that the patch addressed. Buildfarm members
> > platypus and cuckoo are currently failing because dblink is picking
Andrew Dunstan wrote:
> I was also slightly dubious about it. However, we do still need to
> solve the problem that the patch addressed. Buildfarm members
> platypus and cuckoo are currently failing because dblink is picking
> up the wrong libpq (and it appears that incorrect libraries are also
> b
13 matches
Mail list logo
