[PATCHES] Support LDFLAGS_SL on most ports
This patch includes LDFLAGS_SL in SHLIB_LINK on most ports (previously it was only used on AIX and BeOS), and adds support for specifying it in configure. This lets you do something like: ./configure LDFLAGS=-static-libgcc LDFLAGS_SL=-static-libgcc to produce binaries that do not depend on libgcc_s.so at all. I haven't touched the win32/cygwin section of Makefile.shlib as I'm not sure exactly where it'd be useful to add LDFLAGS_SL. -O Index: src/Makefile.global.in === RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v retrieving revision 1.195 diff -u -c -r1.195 Makefile.global.in *** src/Makefile.global.in 18 Sep 2004 13:28:54 - 1.195 --- src/Makefile.global.in 24 Sep 2004 06:23:11 - *** *** 199,204 --- 199,205 with_gnu_ld = @with_gnu_ld@ ld_R_works = @ld_R_works@ LDFLAGS = @LDFLAGS@ + LDFLAGS_SL = @LDFLAGS_SL@ LDREL = -r LDOUT = -o RANLIB = @RANLIB@ Index: src/Makefile.shlib === RCS file: /projects/cvsroot/pgsql-server/src/Makefile.shlib,v retrieving revision 1.78 diff -u -c -r1.78 Makefile.shlib *** src/Makefile.shlib 2 Sep 2004 23:06:43 - 1.78 --- src/Makefile.shlib 24 Sep 2004 06:23:12 - *** *** 276,282 # Normal case $(shlib): $(OBJS) ! $(LINK.shared) $(OBJS) $(SHLIB_LINK) -o $@ # If we're using major and minor versions, then make a symlink to major-version-only. ifneq ($(shlib), $(shlib_major)) rm -f $(shlib_major) --- 276,282 # Normal case $(shlib): $(OBJS) ! $(LINK.shared) $(LDFLAGS_SL) $(OBJS) $(SHLIB_LINK) -o $@ # If we're using major and minor versions, then make a symlink to major-version-only. ifneq ($(shlib), $(shlib_major)) rm -f $(shlib_major) Index: configure.in === RCS file: /projects/cvsroot/pgsql-server/configure.in,v retrieving revision 1.377 diff -u -c -r1.377 configure.in *** configure.in17 Sep 2004 22:31:59 - 1.377 --- configure.in24 Sep 2004 06:23:12 - *** *** 531,536 --- 531,538 AC_MSG_NOTICE([using CPPFLAGS=$CPPFLAGS]) AC_MSG_NOTICE([using LDFLAGS=$LDFLAGS]) + AC_MSG_NOTICE([using LDFLAGS_SL=$LDFLAGS_SL]) + AC_SUBST(LDFLAGS_SL) AC_PROG_AWK ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] cast pid_t to int when using *printf
gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. This patch explicitly casts to int to suppress the warning. -O Index: src/backend/postmaster/pgstat.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/pgstat.c,v retrieving revision 1.80 diff -u -c -r1.80 pgstat.c *** src/backend/postmaster/pgstat.c 29 Aug 2004 05:06:46 - 1.80 --- src/backend/postmaster/pgstat.c 24 Sep 2004 06:46:27 - *** *** 1505,1511 snprintf(pgStat_fname, MAXPGPATH, PGSTAT_STAT_FILENAME, DataDir); /* tmpfname need only be set correctly in this process */ snprintf(pgStat_tmpfname, MAXPGPATH, PGSTAT_STAT_TMPFILE, !DataDir, getpid()); /* * Arrange to write the initial status file right away --- 1505,1511 snprintf(pgStat_fname, MAXPGPATH, PGSTAT_STAT_FILENAME, DataDir); /* tmpfname need only be set correctly in this process */ snprintf(pgStat_tmpfname, MAXPGPATH, PGSTAT_STAT_TMPFILE, !DataDir, (int)getpid()); /* * Arrange to write the initial status file right away Index: src/backend/postmaster/postmaster.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.425 diff -u -c -r1.425 postmaster.c *** src/backend/postmaster/postmaster.c 9 Sep 2004 00:59:33 - 1.425 --- src/backend/postmaster/postmaster.c 24 Sep 2004 06:46:27 - *** *** 2835,2841 */ ereport(DEBUG3, (errmsg_internal(%s child[%d]: starting with (, !progname, getpid(; for (i = 0; i ac; ++i) ereport(DEBUG3, (errmsg_internal(\t%s, av[i]))); --- 2835,2841 */ ereport(DEBUG3, (errmsg_internal(%s child[%d]: starting with (, !progname, (int)getpid(; for (i = 0; i ac; ++i) ereport(DEBUG3, (errmsg_internal(\t%s, av[i]))); ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] cast pid_t to int when using *printf
On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? -Neil ---(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] psql: rollback only last query on error
Michael Paesold [EMAIL PROTECTED] writes: Alvaro Herrera wrote: One potential problem I see with the patch is that it opens lots of savepoints but does not release any. Well, given that EXCEPTION blocks in Pl/pgSQL and the like also never release savepoints That statement is flat wrong. I have to say that I am sorry that I misunderstood that. Regards, Michael Paesold -- +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett: Neil Conway wrote: On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? I don't think there is an escape for pid_t, you always have to cast it. I think what he was asking is this: Since pid_t has to be a signed integer type, but gcc does not accept %d for it, then it could be that pid_t is wider than an int, so casting it to int would potentially lose information. (Btw., the Windows port defines pid_t as unsigned long; that's surely wrong.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] cast pid_t to int when using *printf
(Btw., the Windows port defines pid_t as unsigned long; that's surely wrong.) In what way is that wrong? A PID on Windows is a DWORD, which is an unsigned long. Or am I missing something (probably..)? //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] cast pid_t to int when using *printf
Am Freitag, 24. September 2004 11:06 schrieb Magnus Hagander: (Btw., the Windows port defines pid_t as unsigned long; that's surely wrong.) In what way is that wrong? A PID on Windows is a DWORD, which is an unsigned long. Or am I missing something (probably..)? The mingw header files define pid_t as int, so we shouldn't redefine it in the first place. The rest of the POSIX world also assumes that pid_t is signed, so you might break a bunch of interfaces if it's not. Note that this is independent of the fact that the actual process identifiers are all positive, both on Windows and on Unix systems. (Tertiary note: Never #define one type to another, always use typedef.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
Peter Eisentraut wrote: Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett: Neil Conway wrote: On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? I don't think there is an escape for pid_t, you always have to cast it. I think what he was asking is this: Since pid_t has to be a signed integer type, but gcc does not accept %d for it, then it could be that pid_t is wider than an int, so casting it to int would potentially lose information. pid_t on the Solaris/sparc system is a long (but both int and long are 32 bits). Some experimentation shows that gcc is happy with a %ld format specifier. But compiling the same code on a Linux/x86 system makes gcc complain when applying %ld to pid_t, so we will need a cast there either way. I notice that elog.c casts MyProcPid to long and uses %ld. Amusingly, MyProcPid is explicitly an int.. -O ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
On Fri, 2004-09-24 at 20:31, Oliver Jowett wrote: pid_t on the Solaris/sparc system is a long (but both int and long are 32 bits). Some experimentation shows that gcc is happy with a %ld format specifier. But compiling the same code on a Linux/x86 system makes gcc complain when applying %ld to pid_t, so we will need a cast there either way. I guess it would be safest to use %ld and cast pid_t to long. Of course, this seems a little paranoid -- is there actually a system with sizeof(pid_t) != 4? -Neil ---(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] cast pid_t to int when using *printf
Neil Conway [EMAIL PROTECTED] writes: I guess it would be safest to use %ld and cast pid_t to long. Of course, this seems a little paranoid -- is there actually a system with sizeof(pid_t) != 4? Traditionally PIDs fit in 16 bits, let alone 32. I'd recommend that we standardize on casting pid_t to int for printing purposes; I think that's what's being done in more places than not. Also, as you note, we are using int variables to hold PIDs in many places --- I don't think it's worth running around and changing those either. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Code/comment cleanups now that odbc is gone.
Here ae some code/comment cleanups now that the odbc interface is no longer part of the main distribution. Kris JurkaIndex: src/backend/libpq/md5.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/md5.c,v retrieving revision 1.25 diff -c -r1.25 md5.c *** src/backend/libpq/md5.c 29 Aug 2004 04:12:32 - 1.25 --- src/backend/libpq/md5.c 24 Sep 2004 16:44:03 - *** *** 18,32 */ ! /* ! *NOTE: ! * ! *There are two copies of this file, one in backend/libpq and another ! *in interfaces/odbc. They should be identical. This is done so ODBC ! *can be compiled stand-alone. ! */ ! ! #if ! defined(MD5_ODBC) ! defined(FRONTEND) #include postgres.h #include libpq/crypt.h #endif --- 18,24 */ ! #if ! defined(FRONTEND) #include postgres.h #include libpq/crypt.h #endif *** *** 34,51 #ifdef FRONTEND #include postgres_fe.h #include libpq/crypt.h - #endif /* FRONTEND */ - #ifdef MD5_ODBC - #include md5.h - #endif - - #ifdef FRONTEND #undef palloc #define palloc malloc #undef pfree #define pfree free ! #endif /* --- 26,37 #ifdef FRONTEND #include postgres_fe.h #include libpq/crypt.h #undef palloc #define palloc malloc #undef pfree #define pfree free ! #endif /* FRONTEND */ /* Index: src/include/c.h === RCS file: /projects/cvsroot/pgsql-server/src/include/c.h,v retrieving revision 1.173 diff -c -r1.173 c.h *** src/include/c.h 23 Sep 2004 13:16:02 - 1.173 --- src/include/c.h 24 Sep 2004 16:44:03 - *** *** 231,237 *used for numerical computations and the *frontend/backend protocol. */ - /* Also defined in interfaces/odbc/md5.h */ #ifndef HAVE_UINT8 typedef unsigned char uint8; /* == 8 bits */ typedef unsigned short uint16;/* == 16 bits */ --- 231,236 Index: src/include/libpq/crypt.h === RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/crypt.h,v retrieving revision 1.28 diff -c -r1.28 crypt.h *** src/include/libpq/crypt.h 29 Aug 2004 04:13:07 - 1.28 --- src/include/libpq/crypt.h 24 Sep 2004 16:44:03 - *** *** 15,21 #include libpq/libpq-be.h - /* Also defined in interfaces/odbc/md5.h */ #define MD5_PASSWD_LEN35 #define isMD5(passwd) (strncmp((passwd),md5,3) == 0 \ --- 15,20 *** *** 27,33 extern bool md5_hash(const void *buff, size_t len, char *hexsum); extern bool CheckMD5Pwd(char *passwd, char *storedpwd, char *seed); - /* Also defined in interfaces/odbc/md5.h */ extern bool EncryptMD5(const char *passwd, const char *salt, size_t salt_len, char *buf); --- 26,31 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] libpq verinfo patch
Here is a patch that adds the version info from libpq.rc to the DLL build in mingw. The MSVC build already did this, but it was not linked into the mingw one. This is not the same as the versioninfo patch that's in the queue. Please apply this one before beta-3 if at all possible. //Magnus libpqver.patch Description: libpqver.patch ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] plpython win32
Magnus Hagander [EMAIL PROTECTED] writes: This patch attempts to fix the build of plpython on win32. How is python_includespec going to get set if we don't run the autoconf test that finds it out? I'm quite unthrilled with hardwiring the python version number, as well. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] plpython win32
This patch attempts to fix the build of plpython on win32. How is python_includespec going to get set if we don't run the autoconf test that finds it out? I'm quite unthrilled with hardwiring the python version number, as well. We run the first part of the autoconf test. The one that sets python_includespec. (PGAC_PATH_PYTHON) We just skip the parts that tries to read the Makefile. If there is a good way, that subst command could/should be changed to just strip the last part of the directory. PGAC_PATH_PYTHON appends te python version, which is not correct on win32. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] Translation updates for 8.0: libpq-ru, pg_controldata-ru
Hello, Attached are translation fixes for libpq and pg_controldata to bring them up to date again. Thanks, -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! libpq-ru.po.gz Description: GNU Zip compressed data pg_controldata-ru.po.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] plpython win32
Magnus Hagander wrote: This patch attempts to fix the build of plpython on win32. Needs autoconf of course - don't have mine working on win32, so that part hasn't been 100% tested. My tests involved #:ing out all the code that would be included by that rule, and that makes it work, so I think we're safe Please do not use PORTNAME in external macros. I like to think that one can take these macros and put them in some other project without requiring the prior setup that the PostgreSQL configure.in does. Instead, use AC_REQUIRE([AC_CANONICAL_HOST]) and resolve the issue using $host_os. Also, add some comments to the magic you add in the makefiles. The hardcoded Python version number will of course not stand the test of time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] plpython win32
If there is a good way, that subst command could/should be changed to
just strip the last part of the directory. PGAC_PATH_PYTHON appends
te python version, which is not correct on win32.
I'm curious to know how the code
AC_PATH_PROG(PYTHON, python)
appends the python version.
No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
defined in config/python.m4. The line is:
python_includespec=-I${python_prefix}/include/python${python_version}
//Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] plpython win32
Magnus Hagander wrote:
No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
defined in config/python.m4. The line is:
python_includespec=-I${python_prefix}/include/python${python_version
}
Are we reading the same code?
# PGAC_PATH_PYTHON
#
# Look for Python and set the output variable 'PYTHON'
# to 'python' if found, empty otherwise.
AC_DEFUN([PGAC_PATH_PYTHON],
[AC_PATH_PROG(PYTHON, python)
if test x$PYTHON = x; then
AC_MSG_ERROR([Python not found])
fi
])
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpython win32
No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
defined in config/python.m4. The line is:
python_includespec=-I${python_prefix}/include/python${python_version
}
Are we reading the same code?
# PGAC_PATH_PYTHON
#
# Look for Python and set the output variable 'PYTHON'
# to 'python' if found, empty otherwise.
AC_DEFUN([PGAC_PATH_PYTHON],
[AC_PATH_PROG(PYTHON, python)
if test x$PYTHON = x; then
AC_MSG_ERROR([Python not found])
fi
])
Not quite. Further down in that same file. Seems I mean
PGAC_CHECK_PYTHON_DIRS :-) Not used to these files... I guess that means
that I'm off on the wrong path. :-(
Anyway. The issue is that there is no Makefile in $python_configdir.
That's the part that we need to get rid of. Any pointers? Some kind of
if in python.m4 then probably?
//Magnus
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpython win32
Magnus Hagander [EMAIL PROTECTED] writes: We run the first part of the autoconf test. The one that sets python_includespec. (PGAC_PATH_PYTHON) We just skip the parts that tries to read the Makefile. It would be better to put an if in the PGAC_CHECK_PYTHON_EMBED_SETUP macro, and have it use some other technique for obtaining the info it needs when on Windows. If they don't have a Makefile, one would hope they have some other kind of file that has the needed info. Or doesn't Python support embedding on Windows? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
