cygwin build failure

Andrew Dunstan wrote:

As requested by Reini I set up a Cygwin buildfarm client, and immediately got this build failure:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dshcs00145.o)(.text+0x0): first defined here
Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)
collect2: ld returned 1 exit status
make[3]: *** [pg_dump] Error 1

see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbon&dt=2004-11-06%2018:11:58

The _pg_tolower problem started when I changed exec.c to use the more
standard pg_strcasecmp rather than stricmp. I am confused why this
caused a problem however because libpgport has pg_tolower because it has
pgstrcasecmp.c. Any ideas?

-- 
  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 <pgman@candle.pha.pa.us> writes:

Andrew Dunstan wrote:

/home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'

The _pg_tolower problem started when I changed exec.c to use the more
standard pg_strcasecmp rather than stricmp.

Since it's in an #ifdef WIN32 section, there's probably no harm in
changing it back.

Dunno about the optarg business; it sounds like a DLLIMPORT is needed
someplace, but maybe that is a bug in the Cygwin headers rather than
our bug?

regards, tom lane

Tom Lane schrieb:

Dunno about the optarg business; it sounds like a DLLIMPORT is needed
someplace, but maybe that is a bug in the Cygwin headers rather than
our bug?

No, that's no bug, just diagnostic messages with the new linker.

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o
pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o
pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o
../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq
-lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o
pg_dump.exe

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)
collect2: ld returned 1 exit status
make[3]: *** [pg_dump] Error 1

I'll check how to get rid of that if you want to get rid of it without
grep -v :)
But I don't think that is is easily possible to turn off these purely
diagnostic messages, without cluttering the source with those
__DLL_IMPORT declarations.
And I found no easy ld cmdline override solution. But I'll backcheck.

#ifdef BUILDING_DLL
# ifndef __GNUC__
# define __DLL_IMPORT __declspec(dllimport)
# else
# define __DLL_IMPORT __attribute__((dllimport)) extern
# endif
#else
# define __DLL_IMPORT
#endif
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini Urban schrieb:

Tom Lane schrieb:

Dunno about the optarg business; it sounds like a DLLIMPORT is needed
someplace, but maybe that is a bug in the Cygwin headers rather than
our bug?

No, that's no bug, just diagnostic messages with the new linker.

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o
pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o
pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o
../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq
-lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o
pg_dump.exe

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)
collect2: ld returned 1 exit status
make[3]: *** [pg_dump] Error 1

I'll check how to get rid of that if you want to get rid of it without
grep -v :)
But I don't think that is is easily possible to turn off these purely
diagnostic messages, without cluttering the source with those
__DLL_IMPORT declarations.
And I found no easy ld cmdline override solution. But I'll backcheck.

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini Urban wrote:

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

It's a minor annoyance at worst. Not worth spending effort on. The
issue in these lines is the important one:

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here

cheers

andrew

Andrew Dunstan wrote:

Reini Urban wrote:

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

It's a minor annoyance at worst. Not worth spending effort on. The
issue in these lines is the important one:

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here

Agreed. What could be the solution? I know it is caused by calling
pg_strcasecmp in exec.c.

I think I see it now. I added this to pg_dump/Makefile:

# Not sure why MinGW needs this but it prevents a link failure
# of duplicate definitions for pg_tolower(). 2004-10-06
ifeq ($(PORTNAME), win32)
EXTRA_OBJS += $(top_builddir)/src/port/exec.o
endif

Now, the big question is if you remove this from the Makefile, does
Cygwin compile OK, and if not, why does that fail? I am thinking we
need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual
page has:

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

ranlib [-v|-V] archive

DESCRIPTION
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.

An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
other without regard to their placement in the archive.

The GNU ranlib program is another form of GNU ar; running
ranlib is completely equivalent to executing `ar -s'.

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

I am all wrong on the following. It turns out we need a special linker
flag on Cygwin to allow the linker to link to the first available symbol
in the library (like Unix), and MinGW has a similar flag that we can use
to prevent the pg_dump/Makefile hack on MinGW too!

Working on a patch now.

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

Bruce Momjian wrote:

Andrew Dunstan wrote:

Reini Urban wrote:

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

It's a minor annoyance at worst. Not worth spending effort on. The
issue in these lines is the important one:

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here

Agreed. What could be the solution? I know it is caused by calling
pg_strcasecmp in exec.c.

I think I see it now. I added this to pg_dump/Makefile:

# Not sure why MinGW needs this but it prevents a link failure
# of duplicate definitions for pg_tolower(). 2004-10-06
ifeq ($(PORTNAME), win32)
EXTRA_OBJS += $(top_builddir)/src/port/exec.o
endif

Now, the big question is if you remove this from the Makefile, does
Cygwin compile OK, and if not, why does that fail? I am thinking we
need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual
page has:

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

ranlib [-v|-V] archive

DESCRIPTION
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.

An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
other without regard to their placement in the archive.

The GNU ranlib program is another form of GNU ar; running
ranlib is completely equivalent to executing `ar -s'.

-- 
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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

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

OK, Andrew found the proper flag so Cygwin and MinGW linking will find
the first matching library symbol (like Unix) and not error out because
of multiple definitions.

I have applied the following patch and removed the pg_dump Makefile hack
we had before.

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

Bruce Momjian wrote:

I am all wrong on the following. It turns out we need a special linker
flag on Cygwin to allow the linker to link to the first available symbol
in the library (like Unix), and MinGW has a similar flag that we can use
to prevent the pg_dump/Makefile hack on MinGW too!

Working on a patch now.

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

Bruce Momjian wrote:

Andrew Dunstan wrote:

Reini Urban wrote:

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

It's a minor annoyance at worst. Not worth spending effort on. The
issue in these lines is the important one:

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here

Agreed. What could be the solution? I know it is caused by calling
pg_strcasecmp in exec.c.

I think I see it now. I added this to pg_dump/Makefile:

# Not sure why MinGW needs this but it prevents a link failure
# of duplicate definitions for pg_tolower(). 2004-10-06
ifeq ($(PORTNAME), win32)
EXTRA_OBJS += $(top_builddir)/src/port/exec.o
endif

Now, the big question is if you remove this from the Makefile, does
Cygwin compile OK, and if not, why does that fail? I am thinking we
need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual
page has:

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

ranlib [-v|-V] archive

DESCRIPTION
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.

An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
other without regard to their placement in the archive.

The GNU ranlib program is another form of GNU ar; running
ranlib is completely equivalent to executing `ar -s'.

-- 
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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

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

OK, Andrew found the proper flag so Cygwin and MinGW linking will find
the first matching library symbol (like Unix) and not error out because
of multiple definitions.

I have applied the following patch and removed the pg_dump Makefile hack
we had before.

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

Bruce Momjian wrote:

I am all wrong on the following. It turns out we need a special linker
flag on Cygwin to allow the linker to link to the first available symbol
in the library (like Unix), and MinGW has a similar flag that we can use
to prevent the pg_dump/Makefile hack on MinGW too!

Working on a patch now.

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

Bruce Momjian wrote:

Andrew Dunstan wrote:

Reini Urban wrote:

...

Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

ok, i'm sure now.
there's no way to ignore those diagnostics on the ld side.

It's a minor annoyance at worst. Not worth spending effort on. The
issue in these lines is the important one:

ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe
../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower':
/home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower'
../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here

Agreed. What could be the solution? I know it is caused by calling
pg_strcasecmp in exec.c.

I think I see it now. I added this to pg_dump/Makefile:

# Not sure why MinGW needs this but it prevents a link failure
# of duplicate definitions for pg_tolower(). 2004-10-06
ifeq ($(PORTNAME), win32)
EXTRA_OBJS += $(top_builddir)/src/port/exec.o
endif

Now, the big question is if you remove this from the Makefile, does
Cygwin compile OK, and if not, why does that fail? I am thinking we
need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual
page has:

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

ranlib [-v|-V] archive

DESCRIPTION
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.

An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
other without regard to their placement in the archive.

The GNU ranlib program is another form of GNU ar; running
ranlib is completely equivalent to executing `ar -s'.

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

Index: src/bin/pg_dump/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v
retrieving revision 1.57
diff -c -c -r1.57 Makefile
*** src/bin/pg_dump/Makefile	7 Oct 2004 13:45:48 -0000	1.57
--- src/bin/pg_dump/Makefile	8 Nov 2004 04:56:52 -0000
***************
*** 22,33 ****

EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o

- # Not sure why MinGW needs this but it prevents a link failure
- # of duplicate definitions for pg_tolower(). 2004-10-06
- ifeq ($(PORTNAME), win32)
- EXTRA_OBJS += $(top_builddir)/src/port/exec.o
- endif
-
all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore pg_dumpall

pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(libpq_builddir)/libpq.a 
--- 22,27 ----
Index: src/template/cygwin
===================================================================
RCS file: /cvsroot/pgsql/src/template/cygwin,v
retrieving revision 1.4
diff -c -c -r1.4 cygwin
*** src/template/cygwin	9 Oct 2003 14:40:36 -0000	1.4
--- src/template/cygwin	8 Nov 2004 04:56:55 -0000
***************
*** 1 ****
--- 1,5 ----
SRCH_LIB="/usr/local/lib"
+ # This is required to link pg_dump because it finds pg_toupper() in
+ # libpq and pgport
+ LDFLAGS="-Wl,--allow-multiple-definition"
+ 
Index: src/template/win32
===================================================================
RCS file: /cvsroot/pgsql/src/template/win32,v
retrieving revision 1.2
diff -c -c -r1.2 win32
*** src/template/win32	9 Oct 2003 03:20:34 -0000	1.2
--- src/template/win32	8 Nov 2004 04:56:56 -0000
***************
*** 0 ****
--- 1,4 ----
+ # This is required to link pg_dump because it finds pg_toupper() in
+ # libpq and pgport
+ LDFLAGS="-Wl,--allow-multiple-definition"
+ 

While we are here you could also add -Wl,--enable-auto-import to disable
the diagnostics Andrew complained about on the buildfarm.
Without ld prints this Info: message.
I was wrong in my previous mail. Charles Wilson came up with this hint
to prevent from printing this diagnostic.
http://cygwin.com/ml/cygwin/2004-11/msg00287.html

# This is required to link pg_dump because it finds pg_toupper() in
# libpq and pgport
LDFLAGS="-Wl,--allow-multiple-definition -Wl,--enable-auto-import"
# --enable-auto-import gets rid of a diagnostics linker message
LDFLAGS_SL="-Wl,--enable-auto-import"

FYI: The ranlib step is not needed on win32 platforms.

I'm just testing a new build from CVS with atttached patch.
My latest builds from two weeks ago could only survive
MAX_CONNECTIONS=2. shmget() just crashes with more connections.
Before beta1 I could handle up 50 connections.
But it could also be that shmget is not correctly resolved or
overwritten with 0x0.
Maybe I should turn off bittorrent, emule, mysql and apache...

Bruce, you apparently lost my pg_ctl service starter patch from
http://archives.postgresql.org/pgsql-patches/2004-10/msg00300.php
It's not applied and not in the
http://momjian.postgresql.org/cgi-bin/pgpatches queue

I'm also playing with more port.h patches, having better differences
between WIN32 and __CYGWIN__.

src/interfaces/ecpg/preproc:
the .y and *.l files need to be touched and the generated .c/.h
recompiled. They are outdated, at least on CVS.
pgc.c tries to include "config.h" which is now "pg_config.h"

contrib/pg_autovacuum CPPFLAG override problem:
$ make
gcc -g -fno-strict-aliasing pg_autovacuum.o -L../../src/interfaces/libpq
-lpq -L../../src/port -Wl,--allow-multiple-definition
-Wl,--enable-auto-import -L/usr/local/lib -lpgport -lintl -lssl
-lcrypto -lz -lreadline -lcrypt -lresolv -o pg_autovacuum

fails with undefined references to `_DLNewElem' ...
-I$(srcdir) apparently missing. hmm (scratching my head)

make -p
# `override' directive (from `../../src/makefiles/pgxs.mk', line 70)
CPPFLAGS := -I../../src/interfaces/libpq -I. -I../../src/include
# default
COMPILE.C = $(COMPILE.cc)
# default
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
%.o: %.c
# commands to execute (built-in):
$(COMPILE.c) $(OUTPUT_OPTION) $<

hmm, looks very very strange. The others build just fine, also with the
c.o defaults.
$ make --version
GNU Make 3.80

maybe I should try the make debugger ("remake")
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Hi,

Related to the definition of __DLL_IMPORT below, the cygwin port of
glib/gmodule just does the following:

#define G_MODULE_IMPORT extern
#ifdef G_PLATFORM_WIN32
# define G_MODULE_EXPORT __declspec(dllexport)
#else /* !G_PLATFORM_WIN32 */
# define G_MODULE_EXPORT
#endif /* !G_PLATFORM_WIN32 */

Also, it doesn't make any distinction whether you are building a DLL or not.

The following example has been tested and it works (I've done the
example without gmodule, as we wouldn't want to use that within
postgresql anyways):

dll.h:
extern void foo();

dll.c:
#include "dll.h"

__declspec(dllexport) void foo() {
return;
}

main.c:
#include "dll.h"

int main(int argc, char **argv) {
foo();
return 0;
}

This is with recent GCC (3.3.3 on my system), but it probably also works
with older GCC versions.

Don't know if this information is useful in simplying things...

Maarten

Reini Urban wrote:

Reini Urban <rurban@x-ray.at> writes:

I'm just testing a new build from CVS with atttached patch.

Patch applied.

src/interfaces/ecpg/preproc:
the .y and *.l files need to be touched and the generated .c/.h
recompiled. They are outdated, at least on CVS.

They don't exist in CVS.

regards, tom lane