Re: cygwin build failure - Mailing list pgsql-hackers

From Reini Urban
Subject Re: cygwin build failure
Date
Msg-id 418DDAE9.3080401@x-ray.at
Whole thread Raw
In response to Re: cygwin build failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: cygwin build failure  (Reini Urban <rurban@x-ray.at>)
Re: cygwin build failure  (Maarten Boekhold <boekhold@emirates.net.ae>)
List pgsql-hackers
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.odumputils.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/


pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Proposal for Recover mode in pg_ctl (in 8.0)
Next
From: Simon Riggs
Date:
Subject: Re: Proposal for Recover mode in pg_ctl (in 8.0)