Thanks to Andrew Dunstan, I found the cause of these link errors.
Andrew found this in libintl:

#undef snprintf
#define snprintf libintl_snprintf
extern int snprintf (char *, size_t, const char *, ...);

What is happening is that we do:

#define snprintf pg_snprintf

and then libintl.h (?) does:

#define snprintf libintl_snprintf

so the effect is:

#define pg_snprintf libintl_snprintf

In fact, in this example, the system complains about a missing X3 symbol:

#define X1 X2
#define X2 X3

int
main(int argc, char *argv[])
{
X1;
}

so the effet of the defines is:

#define X1 X3

Anyway, the reason ecpg is failing is that it is the only client-side
program that doesn't use libintl for internationalization. It is on our
TODO list to do that, but it hasn't been done yet.

However, only Win32 is seeing this failure, and only when configure
--enable-nls. I think this is because only Win32 does the redefine of
snprint and friends.

Comments?

---------------------------------------------------------------------------

Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> <pgman@candle.pha.pa.us> wrote:
> >
> > I have applied a modified version of your patch, attached.
>
> I am so sorry, I sent untested patch again. Thank you very
> much for patience in fixing it. The patch looks perfectly
> fine and works under Solaris.
>
> Under win32 I am still struggling with build environment.
> In many directories link fails with "undefined reference to
> `pg_snprintf'" in other it fails with "undefined reference to
> `_imp__libintl_sprintf'". In yet another directory it fails with
> both, like in src/interfaces/ecpg/pgtypeslib:
>
> dlltool --export-all --output-def pgtypes.def numeric.o datetime.o
> common.o dt_common.o timestamp.o interval.o pgstrcasecmp.o
> dllwrap -o libpgtypes.dll --dllname libpgtypes.dll --def pgtypes.def
> numeric.o datetime.o common.o dt_common.o timestamp.o interval.o
> pgstrcasecmp.o -L../../../../src/port -lm
> numeric.o(.text+0x19ea):numeric.c: undefined reference to
> `_imp__libintl_sprintf'
> datetime.o(.text+0x476):datetime.c: undefined reference to `pg_snprintf'
> common.o(.text+0x1cd):common.c: undefined reference to `pg_snprintf'
> common.o(.text+0x251):common.c: undefined reference to `pg_snprintf'
> dt_common.o(.text+0x538):dt_common.c: undefined reference to
> `_imp__libintl_sprintf'
> dt_common.o(.text+0x553):dt_common.c: undefined reference to
> `_imp__libintl_sprintf'
> dt_common.o(.text+0x597):dt_common.c: undefined reference to
> `_imp__libintl_sprintf'
> dt_common.o(.text+0x5d5):dt_common.c: undefined reference to
> `_imp__libintl_sprintf'
> dt_common.o(.text+0x628):dt_common.c: undefined reference to
> `_imp__libintl_sprintf'
> dt_common.o(.text+0x7e8):dt_common.c: more undefined references to
> `_imp__libintl_sprintf' follow
> c:\MinGW\bin\dllwrap.exe: c:\MinGW\bin\gcc exited with status 1
> make: *** [libpgtypes.a] Error 1
>
> Could someone with a better grasp of configure and
> win32 environment check it? Aparently no one regularily
> compiles source code under win32 during development cycle
> these days.
>
>
> Best regards,
> Nicolai
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Bruce Momjian <pgman@candle.pha.pa.us> writes:

> so the effect is:
>
> #define pg_snprintf libintl_snprintf

That's not how CPP works.

> In fact, in this example, the system complains about a missing X3 symbol:
>
> #define X1 X2
> #define X2 X3

In this case any occurrence of X1 replaced by X2 but then the result is
rescanned for macros and X2 is turned into X3.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

After some further digging, I think we have 3 problems.

1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
spot, so I think the thing to do for this problem is a) undo that
hijacking and b) make sure any hijacking we want to do occurs after the
point where that file in included (in c.h). This causes most of the
noise, but is probably harmless, since our hijacking does in fact win
out. We need to fix the arnings, though.

2. We have multiple #defines for snprintf and vsnprintf (in port.h and
win32.h).

3. ecpg wants to use our pg*printf routines (because USE_SNPRINTF is
defined) but doesn't know where to find them.

what a mess :-(

cheers

andrew


Bruce Momjian wrote:

>Thanks to Andrew Dunstan, I found the cause of these link errors.
>Andrew found this in libintl:
>
> #undef snprintf
> #define snprintf libintl_snprintf
> extern int snprintf (char *, size_t, const char *, ...);
>
>What is happening is that we do:
>
> #define snprintf pg_snprintf
>
>and then libintl.h (?) does:
>
> #define snprintf libintl_snprintf
>
>so the effect is:
>
> #define pg_snprintf libintl_snprintf
>
>In fact, in this example, the system complains about a missing X3 symbol:
>
> #define X1 X2
> #define X2 X3
>
> int
> main(int argc, char *argv[])
> {
> X1;
> }
>
>so the effet of the defines is:
>
> #define X1 X3
>
>Anyway, the reason ecpg is failing is that it is the only client-side
>program that doesn't use libintl for internationalization. It is on our
>TODO list to do that, but it hasn't been done yet.
>
>However, only Win32 is seeing this failure, and only when configure
>--enable-nls. I think this is because only Win32 does the redefine of
>snprint and friends.
>
>Comments?
>
>---------------------------------------------------------------------------
>
>Nicolai Tufar wrote:
>
>
>>On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
>><pgman@candle.pha.pa.us> wrote:
>>
>>
>>>I have applied a modified version of your patch, attached.
>>>
>>>
>>I am so sorry, I sent untested patch again. Thank you very
>>much for patience in fixing it. The patch looks perfectly
>>fine and works under Solaris.
>>
>>Under win32 I am still struggling with build environment.
>>In many directories link fails with "undefined reference to
>>`pg_snprintf'" in other it fails with "undefined reference to
>>`_imp__libintl_sprintf'". In yet another directory it fails with
>>both, like in src/interfaces/ecpg/pgtypeslib:
>>
>>dlltool --export-all --output-def pgtypes.def numeric.o datetime.o
>>common.o dt_common.o timestamp.o interval.o pgstrcasecmp.o
>>dllwrap -o libpgtypes.dll --dllname libpgtypes.dll --def pgtypes.def
>>numeric.o datetime.o common.o dt_common.o timestamp.o interval.o
>>pgstrcasecmp.o -L../../../../src/port -lm
>>numeric.o(.text+0x19ea):numeric.c: undefined reference to
>>`_imp__libintl_sprintf'
>>datetime.o(.text+0x476):datetime.c: undefined reference to `pg_snprintf'
>>common.o(.text+0x1cd):common.c: undefined reference to `pg_snprintf'
>>common.o(.text+0x251):common.c: undefined reference to `pg_snprintf'
>>dt_common.o(.text+0x538):dt_common.c: undefined reference to
>>`_imp__libintl_sprintf'
>>dt_common.o(.text+0x553):dt_common.c: undefined reference to
>>`_imp__libintl_sprintf'
>>dt_common.o(.text+0x597):dt_common.c: undefined reference to
>>`_imp__libintl_sprintf'
>>dt_common.o(.text+0x5d5):dt_common.c: undefined reference to
>>`_imp__libintl_sprintf'
>>dt_common.o(.text+0x628):dt_common.c: undefined reference to
>>`_imp__libintl_sprintf'
>>dt_common.o(.text+0x7e8):dt_common.c: more undefined references to
>>`_imp__libintl_sprintf' follow
>>c:\MinGW\bin\dllwrap.exe: c:\MinGW\bin\gcc exited with status 1
>>make: *** [libpgtypes.a] Error 1
>>
>>Could someone with a better grasp of configure and
>>win32 environment check it? Aparently no one regularily
>>compiles source code under win32 during development cycle
>>these days.
>>
>>
>>Best regards,
>>Nicolai
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster
>>
>>
>>
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Andrew Dunstan wrote:
>
> After some further digging, I think we have 3 problems.
>
> 1. On Windows gettext wants to hijack printf and friends, as below. This
> strikes me as rather unfriendly behaviour by a library header file.
> Anyway, mercifully libintl.h is included in our source in exactly one
> spot, so I think the thing to do for this problem is a) undo that
> hijacking and b) make sure any hijacking we want to do occurs after the
> point where that file in included (in c.h). This causes most of the
> noise, but is probably harmless, since our hijacking does in fact win
> out. We need to fix the arnings, though.
>
> 2. We have multiple #defines for snprintf and vsnprintf (in port.h and
> win32.h).
>
> 3. ecpg wants to use our pg*printf routines (because USE_SNPRINTF is
> defined) but doesn't know where to find them.
>
> what a mess :-(

Based on the "mess" analysis, I decided it is better to allow libintl to
use its own snprintf() for Win32 when NLS is enabled, rather than try to
override that with our own snprintf. I have added code to configure.in
so that we don't check for arg control in native snprintf on Win32
because when we are using NLS, we are going to get their snprintf anyway
and not the native one.

Patch attached and applied.

--
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

Index: configure
================================================== =================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.435
diff -c -c -r1.435 configure
*** configure 5 May 2005 11:50:17 -0000 1.435
--- configure 5 May 2005 19:13:35 -0000
***************
*** 14706,14712 ****

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
! if test "$enable_nls" = yes && test $pgac_need_repl_snprintf = no; then
echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 14706,14718 ----

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
! if test "$enable_nls" = yes &&
! test $pgac_need_repl_snprintf = no &&
! # On Win32, libintl replaces snprintf() with its own version that
! # understands arg control, so we don't need our own. In fact, it
! # also uses macros that conflict with ours, so we _can't_ use
! # our own.
! test "$PORTNAME" != "win32"; then
echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: configure.in
================================================== =================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.408
diff -c -c -r1.408 configure.in
*** configure.in 5 May 2005 11:50:18 -0000 1.408
--- configure.in 5 May 2005 19:13:36 -0000
***************
*** 1095,1101 ****

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
! if test "$enable_nls" = yes && test $pgac_need_repl_snprintf = no; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
--- 1095,1107 ----

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
! if test "$enable_nls" = yes &&
! test $pgac_need_repl_snprintf = no &&
! # On Win32, libintl replaces snprintf() with its own version that
! # understands arg control, so we don't need our own. In fact, it
! # also uses macros that conflict with ours, so we _can't_ use
! # our own.
! test "$PORTNAME" != "win32"; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org