CVS HEAD compile failure

fresh checkout just compiled fine for me on Linux (RH8) with ssl
enabled. Maybe it is your openssl installation?

cheers

andrew

Bruce Momjian wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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 requires some other header
to be included beforehand. The syntax errors are likely due to a
typedef name not being defined before use. Does that help?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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 requires some other header
to be included beforehand. The syntax errors are likely due to a
typedef name not being defined before use. Does that help?

Uh, no? :-)

Where is the typedef here:

int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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 openssl (on RH9), and it still
compiled fine (CFLAGS=-H shows the right files being picked up).

Can you give us the complete config settings? Maybe some interaction
between them has found a bug somewhere.

(BTW, the INSTALL file says you can use --with-openssl=/path but
configure barfs on it - we need to fix one or the other).

cheers

andrew

Bruce Momjian <pgman@candle.pha.pa.us> 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

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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 this function)

(assuming he is using gcc)?

cheers

andrew

Bruce Momjian <pgman@candle.pha.pa.us> 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 reproduce this on one of my machines, and it's nasty.
It's a conflict between other people's headers.

/usr/local/include/zlib.h (version 1.1.4) quoth:

typedef void (*free_func) OF((voidpf opaque, voidpf address));

/usr/local/ssl/include/openssl/crypto.h (0.9.7c) quoth:

int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));

So if this version of zlib.h is included before this version of
crypto.h, things break. Other way 'round works fine.

We can work around this by being more careful about inclusion order
of these headers. Ultimately it would be nice if the upstream library
authors could avoid the name conflict. 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.

regards, tom lane

Andrew Dunstan <andrew@dunslane.net> 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

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 maintain
interface compatibility.

mark

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 language, they change the syntactical value of the
identifier. The parser actually has to know whether an identifier is a typedef
or not in order to figure out how to parse the code.

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.

--
greg

Greg Stark <gsstark@mit.edu> 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 the other way round: a name that the
code did not expect to be a typedef was being taken as one. But yeah,
"impossible" syntax errors in C code are often a symptom of typedef
trouble.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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 reproduce this on one of my machines, and it's nasty.
It's a conflict between other people's headers.

/usr/local/include/zlib.h (version 1.1.4) quoth:

typedef void (*free_func) OF((voidpf opaque, voidpf address));

/usr/local/ssl/include/openssl/crypto.h (0.9.7c) quoth:

int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *));

So if this version of zlib.h is included before this version of
crypto.h, things break. Other way 'round works fine.

We can work around this by being more careful about inclusion order
of these headers. Ultimately it would be nice if the upstream library
authors could avoid the name conflict. 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.

In that case I'm confused about why this code compiles on my machine:

----------------
#include <stdio.h>
#include <zconf.h>

typedef voidpf (*alloc_func) OF((voidpf opaque, uInt items, uInt size));
typedef void (*free_func) OF((voidpf opaque, voidpf address));

int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void
(*free_func)(void *));

int main()
{
return 0;
}
--------------------

Also, in compiling pg_dump/common.c, zlib.h (which has this typedef on
my machine) *is* included before openssl/crypto.h.

Either there is something I'm not getting (quite possible ;-) ), or the
problem lies deeper. (compiler version maybe?)

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> 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), and I think Bruce is also using something less than
the latest. It's possible that more recent gcc's are able to figure out
that the reference to free_func should be interpreted as a parameter
name and not a typedef.

In fact, trying your test program fails here:

$ gcc -Wall zzz.c
zzz.c:8: parse error before `free_func'
zzz.c:8: parse error before `)'
$

so "compiler difference" definitely seems to be the answer.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> 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), and I think Bruce is also using something less than
the latest. It's possible that more recent gcc's are able to figure out
that the reference to free_func should be interpreted as a parameter
name and not a typedef.

In fact, trying your test program fails here:

$ gcc -Wall zzz.c
zzz.c:8: parse error before `free_func'
zzz.c:8: parse error before `)'
$

so "compiler difference" definitely seems to be the answer.

gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

cheers

andrew

Kurt Roeckx wrote:

On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> 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)

I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
zlib 1.2.1.

zlib 1.2.1 still has the same typedef though.

compile success with gcc 2.96 here.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> 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)

I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
zlib 1.2.1.

zlib 1.2.1 still has the same typedef though.

Kurt

Tom Lane wrote:

Kurt Roeckx <Q@ping.be> 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?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Kurt Roeckx <Q@ping.be> 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

Jan Wieck <JanWieck@Yahoo.com> 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 vulnerable.

regards, tom lane

Tom Lane wrote:

Kurt Roeckx <Q@ping.be> 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.

Looking around the web I see that we aren't the first people to trip
over this. In fact the issue has been known for years - I saw a
reference to it all the way back to 1999.

Another project solved it by adjusting the namespace pollution instead
of changing the include order, thus:

+#define free_func zlib_free_func
 #include <zlib.h>
+#undef free_func

Anyway, I hope it's fixed :-)

cheers

andrew