Fresh checkout of CVS HEAD yesterday, updated today :
$ ./configure --prefix=/usr/local/pgsql/7.5
$ make
gmake[4]: Entering directory
`/usr/home/postgres/develop/c/pgsql/src/backend/access/nbtree'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../../src/in
Just updated now. compiles. fast fix :-)
Tom Lane wrote:
I plan to fix that later tonight
if no one beats me to it.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.or
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What Win32 has done is to centralize all delay calls around that
> > function, now renamed PG_USLEEP/PG_MSLEEP. I was going to add the
> > missing includes but if you want to centralize it, I think that makes
> > more sense.
>
> Yeah
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What Win32 has done is to centralize all delay calls around that
> function, now renamed PG_USLEEP/PG_MSLEEP. I was going to add the
> missing includes but if you want to centralize it, I think that makes
> more sense.
Yeah, I'm planning to add a "pgsle
Tom Lane wrote:
> Vsevolod Lobko <[EMAIL PROTECTED]> writes:
> > Yes, here too...
> > There are no headers included for struct timeval and function select
> > in miscadmin.h
>
> Certain parties who shall remain nameless have been gratuitously
> scattering dependencies on select() into lots of mod
Vsevolod Lobko <[EMAIL PROTECTED]> writes:
> Yes, here too...
> There are no headers included for struct timeval and function select
> in miscadmin.h
Certain parties who shall remain nameless have been gratuitously
scattering dependencies on select() into lots of modules that don't
need them. (W
Yes, here too...
There are no headers included for struct timeval and function select
in miscadmin.h
adding #include fixes the problem on freebsd, but I'm sure it's not
a portable solution...
Index: miscadmin.h
===
RCS file: /home
On Monday, December 8, 2003, at 08:29 AM, Tom Lane wrote:
I'm of the opinion that zlib
should not be typedef'ing a name as generic as "free_func", but if
they've made that part of their exported API, it might be hard for them
to change.
Yes, that was a mistake. However we're stuck with it to maint
Tom Lane wrote:
Kurt Roeckx <[EMAIL PROTECTED]> writes:
I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
zlib 1.2.1.
"current CVS" meaning "since I fixed the include order" ?
The little code snippet I posted earlier should do to test out
compilers, if people want to.
Lookin
Jan Wieck <[EMAIL PROTECTED]> writes:
> Good question. Using my cvsup tree here, which I did sup today already.
> So what -D would trigger the failure?
Hopefully, you can't ...
If you revert src/bin/pg_dump/pg_backup_archiver.h to version 1.54
you'd see the problem, assuming your compiler is vul
Tom Lane wrote:
Kurt Roeckx <[EMAIL PROTECTED]> writes:
I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
zlib 1.2.1.
"current CVS" meaning "since I fixed the include order" ?
Good question. Using my cvsup tree here, which I did sup today already.
So what -D would trigger the failure?
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
> zlib 1.2.1.
"current CVS" meaning "since I fixed the include order" ?
regards, tom lane
---(end of broadcast)---
TIP 9
Kurt Roeckx wrote:
On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been able to reproduce this on one of my machines, and it's nasty.
> In that case I'm confused about why this code compiles on my machine:
What compile
On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've been able to reproduce this on one of my machines, and it's nasty.
>
> > In that case I'm confused about why this code compiles on my machine:
>
> What compiler are
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I've been able to reproduce this on one of my machines, and it's nasty.
In that case I'm confused about why this code compiles on my machine:
What compiler are you using? I'm using gcc 2.95.3 (on the
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been able to reproduce this on one of my machines, and it's nasty.
> In that case I'm confused about why this code compiles on my machine:
What compiler are you using? I'm using gcc 2.95.3 (on the machine that
shows the failure
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?
It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can
be my SSL insta
Greg Stark <[EMAIL PROTECTED]> writes:
> Syntax errors in known good code, especially header files are a typical
> symptom of missing typedefs. A good thing to know to recognize right away or
> else you'll spend lots of time puzzling over seemingly good code.
Actually it turns out the error was th
> >> int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void
> >> *));
>
> If there's a missing typedef shouldn't we see something like this:
>
> `size_t' undeclared (first use in this function)
>
> (assuming he is using gcc)?
Try it.
typedefs are weird in the C l
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> (BTW, the INSTALL file says you can use --with-openssl=/path but
Only because it hasn't yet been rebuilt from installation.sgml.
regards, tom lane
---(end of broadcast)---
TIP 2:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> fresh checkout just compiled fine for me on Linux (RH8) with ssl
>> enabled. Maybe it is your openssl installation?
> It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can
> be my SSL install.
I've been able to
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Where is the typedef here:
int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));
size_t ...
If there's a missing typedef shouldn't we see something like this:
`size_t' undeclared (first use in thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where is the typedef here:
> int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));
size_t ...
regards, tom lane
---(end of broadcast)---
TIP 8: expl
Bruce Momjian wrote:
Andrew Dunstan wrote:
fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?
It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can
be my SSL install.
I just tried with this version of openss
Andrew Dunstan wrote:
>
> fresh checkout just compiled fine for me on Linux (RH8) with ssl
> enabled. Maybe it is your openssl installation?
It is openssl 0.9.7c. 7.4 CVS compiles fine so I don't see how it can
be my SSL install.
--
Bruce Momjian| http://candle.pha.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
>
> Hmm. I made some what-I-thought-were-unimportant changes in the order
> of header inclusions in pg_dump. Probably what you are seeing is a
> previously unnoti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
Hmm. I made some what-I-thought-were-unimportant changes in the order
of header inclusions in pg_dump. Probably what you are seeing is a
previously unnoticed case of some header that
fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?
cheers
andrew
Bruce Momjian wrote:
Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
The offending lines are:
gmake[3]: Leaving directory `/usr/var/local/src
Attached is a compile failure I am seeing in CVS HEAD in bin/pg_dump.
The offending lines are:
gmake[3]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/backend/parser'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations
-O1 -
On Fri, Aug 01, 2003 at 10:22:59AM -0700, Joe Conway wrote:
> Looks like a simple matter of replacing "replace_int64" with "int64_val"
> at line 549 in src/interfaces/ecpg/pgtypeslib/timestamp.c
Yes, it is. Thanks. I didn't have HAVE_INT64_TIMESTAMP defined.
In fact there's another one in common
Joe Conway wrote:
I'm getting an ecpg related compile failure on cvs tip:
gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
-I../../../../src/interfaces/ecpg/include
-I../../../../src/include/utils -I../../../../src/include -g -c -o
timestamp.o timestamp.c -MMD
timestamp.c: I
I'm getting an ecpg related compile failure on cvs tip:
gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
-I../../../../src/interfaces/ecpg/include
-I../../../../src/include/utils -I../../../../src/include -g -c -o
timestamp.o timestamp.c -MMD
timestamp.c: In function `dttofm
32 matches
Mail list logo
