[PATCHES] cypg.dll, libpq_a, initdb max_connections 60

[Reini Urban]

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/msg2.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.orig2004-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.orig2004-08-29 06:13:01.0 
+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 [EMAIL PROTECTED](X)
+initdb: $(OBJS) $(libpq_a)
+   $(CC) $(CFLAGS) $(OBJS) $(libpq_a) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](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.0 +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)

Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60

[Tom Lane]

Reini Urban [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60

[Reini Urban]

Tom Lane schrieb:
Reini Urban [EMAIL PROTECTED] 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/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60

[Magnus Hagander]

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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org