"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
>> 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 t
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 Pyth
>> 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".
Magnus Hagander wrote:
> 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 pyth
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
> t
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 | /
>> 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
"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.
Hi!
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
//Magnu
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
li
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 re
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
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
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
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 file
> (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: H
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 f
> "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
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, yo
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)--
21 matches
Mail list logo
