I'm in the process of creating some patches to fix the Cygwin specific
build issues mentioned in the following post:

    http://archives.postgresql.org/pgsql-cygwin/2003-04/msg00053.php

I was able to resolve all problems except for the following:

    1. src/include/port/win32defs.h does not seem to be in CVS yet.

    2. ecpg_compat_mode is declared in
       src/interfaces/ecpg/ecpglib/connect.c but does not seem to be
       defined yet.

Also, I would like to know whether or not the following is an acceptable
way to get ecpg.dll linked against libpgtypes.a:

    +++ interfaces/ecpg/ecpglib/Makefile    2003/04/29 17:40:25
    @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o 
        connect.o misc.o

     SHLIB_LINK= $(libpq)
    +ifeq ($(PORTNAME), cygwin)
    +SHLIB_LINK+= -L../pgtypeslib -lpgtypes
    +endif

If not, what is the recommended approach?

Any help with the above will be greatly appreciated.

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


Tue, 29 Apr 2003 14:14:32 -0400
Jason Tishler <jason@tishler.net>
Cygwin PostgreSQL CVS build issues
Jason Tishler wrote:
> I'm in the process of creating some patches to fix the Cygwin specific
> build issues mentioned in the following post:
> 
>     http://archives.postgresql.org/pgsql-cygwin/2003-04/msg00053.php
> 
> I was able to resolve all problems except for the following:
> 
>     1. src/include/port/win32defs.h does not seem to be in CVS yet.

Requirement removed.  That file isn't needed anymore.

>     2. ecpg_compat_mode is declared in
>        src/interfaces/ecpg/ecpglib/connect.c but does not seem to be
>        defined yet.
> 
> Also, I would like to know whether or not the following is an acceptable
> way to get ecpg.dll linked against libpgtypes.a:
> 
>     +++ interfaces/ecpg/ecpglib/Makefile    2003/04/29 17:40:25
>     @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o 
>         connect.o misc.o
> 
>      SHLIB_LINK= $(libpq)
>     +ifeq ($(PORTNAME), cygwin)
>     +SHLIB_LINK+= -L../pgtypeslib -lpgtypes
>     +endif
> 
> If not, what is the recommended approach?

Michael Meskes will have to answer these.

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


Tue, 29 Apr 2003 14:26:39 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Cygwin PostgreSQL CVS build issues
Jason Tishler <jason@tishler.net> writes:
> Also, I would like to know whether or not the following is an acceptable
> way to get ecpg.dll linked against libpgtypes.a:

>     +++ interfaces/ecpg/ecpglib/Makefile    2003/04/29 17:40:25
>     @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o 
>         connect.o misc.o

>      SHLIB_LINK= $(libpq)
>     +ifeq ($(PORTNAME), cygwin)
>     +SHLIB_LINK+= -L../pgtypeslib -lpgtypes
>     +endif

Why would Cygwin need that if other platforms don't?  (Perhaps other
platforms do too?  I've never tried to actually run ecpg ...)

			regards, tom lane


Tue, 29 Apr 2003 15:36:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Cygwin PostgreSQL CVS build issues 
Tom,

On Tue, Apr 29, 2003 at 03:36:34PM -0400, Tom Lane wrote:
> Jason Tishler <jason@tishler.net> writes:
> > Also, I would like to know whether or not the following is an
> > acceptable way to get ecpg.dll linked against libpgtypes.a:
> >
> > [snip]
> 
> Why would Cygwin need that if other platforms don't?

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.

> (Perhaps other platforms do too? ...)

I don't know.  Are their other platforms with "shared" libraries that
have the same link time requirement as Windows?

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


Tue, 29 Apr 2003 16:23:37 -0400
Jason Tishler <jason@tishler.net>
Re: Cygwin PostgreSQL CVS build issues
Bruce,

On Tue, Apr 29, 2003 at 02:26:39PM -0400, Bruce Momjian wrote:
> Jason Tishler wrote:
> > I was able to resolve all problems except for the following:
> > 
> >     1. src/include/port/win32defs.h does not seem to be in CVS yet.
> 
> Requirement removed.  That file isn't needed anymore.

Should one of my forthcoming patches remove the above mentioned
#include?  Or, will you take care of this?

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


Tue, 29 Apr 2003 16:25:53 -0400
Jason Tishler <jason@tishler.net>
Re: Cygwin PostgreSQL CVS build issues
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.  You can just as well dynamicly load
dll's in windows.  Maybe it's just that cygwin doesn't do it.


Kurt


Tue, 29 Apr 2003 22:42:35 +0200
Kurt Roeckx <Q@ping.be>
Re: Cygwin PostgreSQL CVS build issues
Jason Tishler wrote:
> Bruce,
> 
> On Tue, Apr 29, 2003 at 02:26:39PM -0400, Bruce Momjian wrote:
> > Jason Tishler wrote:
> > > I was able to resolve all problems except for the following:
> > > 
> > >     1. src/include/port/win32defs.h does not seem to be in CVS yet.
> > 
> > Requirement removed.  That file isn't needed anymore.
> 
> Should one of my forthcoming patches remove the above mentioned
> #include?  Or, will you take care of this?

I can handle it.

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


Tue, 29 Apr 2003 17:05:14 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Cygwin PostgreSQL CVS build issues
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


Wed, 30 Apr 2003 08:28:39 -0400
Jason Tishler <jason@tishler.net>
Re: Cygwin PostgreSQL CVS build issues