Re: Cygwin PostgreSQL CVS build issues - Mailing list pgsql-hackers
From | Jason Tishler |
---|---|
Subject | Re: Cygwin PostgreSQL CVS build issues |
Date | |
Msg-id | 20030430122838.GA1372@tishler.net Whole thread Raw |
In response to | Re: Cygwin PostgreSQL CVS build issues (Kurt Roeckx <Q@ping.be>) |
List | pgsql-hackers |
Kurt, On Tue, Apr 29, 2003 at 10:42:35PM +0200, Kurt Roeckx wrote: > On Tue, Apr 29, 2003 at 04:23:37PM -0400, Jason Tishler wrote: > > Why? Because Cygwin is Windows after all... :,) > > > > DLLs, unlike shared libraries under Unix, need all symbols resolved > > at link as opposed to load time. AFAICT, this is why constructs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **************************** > > like BE_DLLLIBS are part of PostgreSQL's makefiles. > > That's not true at all. Unfortunately, it is. Otherwise, porting Unix software with shared library components to Cygwin would be much easier. > You can just as well dynamicly load dll's in windows. Of course, but this fact is irrelevant to the discussion. See below... > Maybe it's just that cygwin doesn't do it. No, Cygwin has dlopen() and friends. It appears that you did not read my previous post carefully or you misunderstood it -- in particular the phrase marked by asterisks above. By "link" and "load" time, I meant build and run time, respectively. This is a build issue (as indicated by the subject) and has nothing to do with dynamically loading DLLs at run time. A Windows DLL must have *all* symbols resolved at link (i.e., build) time. Otherwise, the link with fail. Unfortunately, this is a basic Windows DLL requirement. Since ecpg.dll is dependent on pgtypes.dll, it must be linked against libpgtypes.a (i.e., the corresponding import library). Otherwise, the link will fail with errors like to following: dllwrap -o ecpg.dll --dllname ecpg.dll --def ecpg.def execute.o ... execute.o(...):execute.c: undefined reference to`_PGTYPESnumeric_to_asc' execute.o(...):execute.c: undefined reference to `_PGTYPESnumeric_to_asc' execute.o(...):execute.c:undefined reference to `_PGTYPESdate_to_asc' ... Additionally, PostgreSQL is already linking against libpostgres.a (i.e, the import library for postgres.exe) under Cygwin in many places: $ find . -type f | xargs fgrep BE_DLLLIBS ./backend/utils/mb/conversion_procs/proc.mk:SHLIB_LINK := $(BE_DLLLIBS) ./makefiles/Makefile.cygwin:BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres ./makefiles/Makefile.win:BE_DLLLIBS=-L$(top_builddir)/src/backend -lpostgres ./pl/plperl/GNUmakefile:SHLIB_LINK = $(perl_embed_ldflags)$(BE_DLLLIBS) ./pl/plpgsql/src/Makefile:SHLIB_LINK = $(BE_DLLLIBS) ./pl/plpython/Makefile:SHLIB_LINK= $(BE_DLLLIBS) $(python_libspec) ./test/regress/GNUmakefile:SHLIB_LINK = $(BE_DLLLIBS) ./tutorial/Makefile:SHLIB_LINK = $(BE_DLLLIBS) Hence, the need to link with the necessary import libraries under Cygwin is very real and cannot be avoided. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
pgsql-hackers by date: