Re: cygwin build failure

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Reini Urban <rurban(at)x-ray(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cygwin build failure
Date: 2004-11-08 05:22:08
Message-ID: 200411080522.iA85M8M12031@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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

Attachment Content-Type Size
unknown_filename text/plain 1.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-11-08 06:12:52 Re: Increasing the length of pg_stat_activity.current_query...
Previous Message Greg Stark 2004-11-08 04:34:39 Re: Increasing the length of pg_stat_activity.current_query...

Browse pgsql-patches by date

  From Date Subject
Next Message Fabien COELHO 2004-11-08 07:15:57 Re: pgxs under Win32 for PL/Java
Previous Message John Hansen 2004-11-08 01:49:08 Re: calling currval() before nextval() patch adding