Re: cygwin build failure

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/