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
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
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
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
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
(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:
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
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,
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
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
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
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
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.
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
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 |
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
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
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
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
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
20 matches
Mail list logo
