Thread: cypg.dll, libpq_a, initdb max_connections 60

1. cyg-pgdll.patch
For the cygwin port I found out that we'd need a better name for libpq
libraries only, and that the name pq.dll is not a good one. It would
clash with the mingw version, which might get copied into the path.
We have out own standards, esp. when dealing with import libs, which
would require the "cyg" prefix for pq.dll.

I also did't find the version-info linker switches, though I found some
discussion that it should be used. Even WIN32 has versioning now via the
.rc. So added them for our port. You might want that also for all gnu
gcc ports.

This patch is for src/bin/pg_ctl/Makefile only.
With this patch we might want to rename libpq.a to libpq.dll.a in our
install step later.

2. cyg-pgdll+libpq_a.patch
Rename to libpq.dll.a and cygpq.dll.
The former patch is not needed then.
Reason: We have some magic dealing with -lpq, which picks up
/usr/lib/libpq.dll.a automatically.
Esp. libtool is not very clever, when trying to use old-style libpq.a
name. This patch has to deal with the $(libpq_builddir)/libpq.a
dependency in src/bin/*/Makefile and src/interfaces/libpq/Makefile.
It also changes the linker line to always pick up our current libpq.a
instead of -L$(libpq_builddir) -lpq.

This is not a must for cygwin. cyg-pgdll.patch would be enough.
It is also not perfect: Because of some overriding (have to study info
make) it recompiles cygpg.dll and libpg.dll.a for every client target.

PS: I personally would vastly prefer libtool.
The .la files will help immensily in testing and installing. But this is
only an issue for libpg, and probably not worth the effort.

3. cyg-initdb.patch
limit initdb max_connections for cygwin.
cygwin has a hard-coded limit of max 63 subprocesses in cygwin1.dll.
So 100 is not a good value to start with. I've set that to 60.
   http://archives.postgresql.org/pgsql-cygwin/2002-09/msg00002.php
Fixing src/backend/utils/misc/postgresql.conf.sample would be stupid.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

*** postgresql-8.0.0cvs/src/interfaces/libpq/Makefile.orig    Sun Sep 26 04:14:47 2004
--- postgresql-8.0.0cvs/src/interfaces/libpq/Makefile    Sat Oct  9 15:17:01 2004
***************
*** 27,32 ****
--- 27,36 ----
      dllist.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o \
      $(filter crypt.o getaddrinfo.o inet_aton.o open.o snprintf.o strerror.o, $(LIBOBJS))

+ ifeq ($(PORTNAME), cygwin)
+ override shlib = cyg$(NAME)$(DLSUFFIX)
+ endif
+
  ifeq ($(PORTNAME), win32)
  OBJS+=win32.o libpqrc.o
  libpqrc.o: libpq.rc
***************
*** 54,59 ****
--- 58,70 ----
  include $(top_srcdir)/src/Makefile.shlib
  backend_src = $(top_srcdir)/src/backend

+ ifeq ($(PORTNAME), cygwin)
+ $(shlib) lib$(NAME).dll.a: $(OBJS) $(DLLINIT)
+     $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --dllname $(shlib) --output-def $(NAME).def $(OBJS)
+     $(DLLWRAP) -Wl,--major-image-version,$(SO_MAJOR_VERSION) -Wl,--minor-image-version,$(SO_MINOR_VERSION) \
+       -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def $(OBJS) $(DLLINIT) $(SHLIB_LINK)
+     $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def --output-lib lib$(NAME).a
+ endif

  # We use several backend modules verbatim, but since we need to
  # compile with appropriate options to build a shared lib, we can't
--- postgresql-8.0.0cvs/src/Makefile.global.orig    2004-10-07 04:46:04.409784800 +0200
+++ postgresql-8.0.0cvs/src/Makefile.global    2004-10-09 14:46:47.034467200 +0200
@@ -302,6 +302,11 @@
 endif

 libpq = -L$(libpq_builddir) -lpq
+ifeq ($(PORTNAME), cygwin)
+libpq_a=  $(libpq_builddir)/libpq.dll.a
+else
+libpq_a = $(libpq_builddir)/libpq.a
+endif

 submake-libpq:
     $(MAKE) -C $(libpq_builddir) all
--- postgresql-8.0.0cvs/src/bin/initdb/Makefile.orig    2004-08-29 06:13:01.000000000 +0200
+++ postgresql-8.0.0cvs/src/bin/initdb/Makefile    2004-10-09 14:29:31.766468800 +0200
@@ -19,8 +19,8 @@

 all: submake-libpq submake-libpgport initdb

-initdb: $(OBJS) $(libpq_builddir)/libpq.a
-    $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@$(X)
+initdb: $(OBJS) $(libpq_a)
+    $(CC) $(CFLAGS) $(OBJS) $(libpq_a) $(LDFLAGS) $(LIBS) -o $@$(X)

 dirmod.c: % : $(top_srcdir)/src/port/%
     rm -f $@ && $(LN_S) $< .
--- postgresql-8.0.0cvs/src/interfaces/libpq/Makefile.orig    2004-09-26 04:14:47.000000000 +0200
+++ postgresql-8.0.0cvs/src/interfaces/libpq/Makefile    2004-10-09 14:52:14.827146400 +0200
@@ -27,6 +27,10 @@
     dllist.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o \
     $(filter crypt.o getaddrinfo.o inet_aton.o open.o snprintf.o strerror.o, $(LIBOBJS))

+ifeq ($(PORTNAME), cygwin)
+override shlib = cyg$(NAME)$(DLSUFFIX)
+endif
+
 ifeq ($(PORTNAME), win32)
 OBJS+=win32.o libpqrc.o
 libpqrc.o: libpq.rc
@@ -54,6 +58,13 @@
 include $(top_srcdir)/src/Makefile.shlib
 backend_src = $(top_srcdir)/src/backend

+ifeq ($(PORTNAME), cygwin)
+$(shlib) lib$(NAME).dll.a: $(OBJS) $(DLLINIT)
+    $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --dllname $(shlib) --output-def $(NAME).def $(OBJS)
+    $(DLLWRAP) -Wl,--major-image-version,$(SO_MAJOR_VERSION) -Wl,--minor-image-version,$(SO_MINOR_VERSION) \
+      -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def $(OBJS) $(DLLINIT) $(SHLIB_LINK)
+    $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def --output-lib lib$(NAME).dll.a
+endif

 # We use several backend modules verbatim, but since we need to
 # compile with appropriate options to build a shared lib, we can't
*** postgresql-8.0.0cvs/src/bin/initdb/initdb.c.orig    Thu Sep  2 19:58:41 2004
--- postgresql-8.0.0cvs/src/bin/initdb/initdb.c    Sat Oct  9 14:40:13 2004
***************
*** 981,987 ****
--- 981,991 ----
  test_connections(void)
  {
      char        cmd[MAXPGPATH];
+ #ifdef __CYGWIN__
+     static const int conns[] = {60, 50, 40, 30, 20, 10, 5};
+ #else
      static const int conns[] = {100, 50, 40, 30, 20, 10};
+ #endif
      static const int len = sizeof(conns) / sizeof(int);
      int            i,
                  status;

Reini Urban <rurban@x-ray.at> writes:
> With this patch we might want to rename libpq.a to libpq.dll.a in our
> install step later.

Isn't ".dll.a" a contradiction in terms?  This doesn't seem
well-thought-out at all to me.  Also the end result would have to
be much more invasive than you suggest here, since there are many
more programs besides pg_ctl that use libpq.

> + #ifdef __CYGWIN__
> +     static const int conns[] = {60, 50, 40, 30, 20, 10, 5};
> + #else
>       static const int conns[] = {100, 50, 40, 30, 20, 10};
> + #endif

This part is just silly.  If your system can't support ten connections
I think you need to fix your system.  Also, we are not in the habit of
plastering the source with platform-specific ifdefs just to save a
couple of cycles during initialization.  If the probe at 100 caused an
actual failure on cygwin, I'd accept such a patch, but not otherwise.
How legible do you think this code would be if we tried to #ifdef in
platform-specific limits for every port we support?

            regards, tom lane

Tom Lane schrieb:
> Reini Urban <rurban@x-ray.at> writes:
>>With this patch we might want to rename libpq.a to libpq.dll.a in our
>>install step later.
>
> Isn't ".dll.a" a contradiction in terms?  This doesn't seem
> well-thought-out at all to me.  Also the end result would have to
> be much more invasive than you suggest here, since there are many
> more programs besides pg_ctl that use libpq.

".dll.a": well, that's the fact.
I had terrible problems in compiling apps which link to libpq.a, which
actually is libtool problem. it's has very very low urgency.

invasiveness: see the libpq_a patch.
I wonder why you link all clients statically. with a libpq macro you
could decide to which version (shared or static) you want to link against.

>>+ #ifdef __CYGWIN__
>>+     static const int conns[] = {60, 50, 40, 30, 20, 10, 5};
>>+ #else
>>      static const int conns[] = {100, 50, 40, 30, 20, 10};
>>+ #endif
>
>
> This part is just silly.  If your system can't support ten connections
> I think you need to fix your system.  Also, we are not in the habit of
> plastering the source with platform-specific ifdefs just to save a
> couple of cycles during initialization.  If the probe at 100 caused an
> actual failure on cygwin, I'd accept such a patch, but not otherwise.
> How legible do you think this code would be if we tried to #ifdef in
> platform-specific limits for every port we support?

arguments accepted.
though the probe for cygwin at 100 causes it NOT to fail.
this is actually a more severe problem.
It'll stay in my private patches archive.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

>1. cyg-pgdll.patch
>For the cygwin port I found out that we'd need a better name for libpq
>libraries only, and that the name pq.dll is not a good one. It would
>clash with the mingw version, which might get copied into the path.
>We have out own standards, esp. when dealing with import libs, which
>would require the "cyg" prefix for pq.dll.

The mingw library is "libpq.dll", not "pq.dll". If cygwin uses just
"pq.dll" there will be no clash.

Same for the native win32 version, which has been around for years.


//Magnus

Magnus Hagander schrieb:
>>1. cyg-pgdll.patch
>>For the cygwin port I found out that we'd need a better name for libpq
>>libraries only, and that the name pq.dll is not a good one. It would
>>clash with the mingw version, which might get copied into the path.
>>We have out own standards, esp. when dealing with import libs, which
>>would require the "cyg" prefix for pq.dll.
>
>
> The mingw library is "libpq.dll", not "pq.dll". If cygwin uses just
> "pq.dll" there will be no clash.
>
> Same for the native win32 version, which has been around for years.

Thanks. Good to know.
Nevertheless I would prefer the cyg prefix,
and also some DLL versioning.

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/