FW: Postgresql on win32
Seems this one got lost along the way somewhere. At least, I didn't get it
back... Trying a resend.
//Magnus
Show quoted text
-----Original Message-----
From: Magnus Hagander
Sent: den 20 januari 2001 14:29
To: 'pgsql-hackers@postgresql.org'
Subject: Postgresql on win32Hello!
Here is a patch to make the current snapshot compile on Win32
(native, libpq and psql) again. Changes are:
1) psql requires the includes of "io.h" and "fcntl.h" in
command.c in order to make a call to open() work (io.h for
_open(), fcntl.h for the O_xxx)
2) PG_VERSION is no longer defined in version.h[.in], but in
configure.in. Since we don't do configure on native win32, we
need to put it in config.h.win32 :-(
3) Added define of SYSCONFDIR to config.h.win32 - libpq won't
compile without it. This functionality is *NOT* tested - it's
just defined as "" for now. May work, may not.
4) DEF_PGPORT renamed to DEF_PGPORT_STRI have done the "basic tests" on it - it connects to a
database, and I can run queries. Haven't tested any of the
fancier functions (yet).However, I stepped on a much bigger problem when fixing psql
to work. It no longer works when linked against the .DLL
version of libpq (which the Makefile does for it). I have
left it linked against this version anyway, pending the
comments I get on this mail :-)
The problem is that there are strings being allocated from
libpq.dll using PQExpBuffers (for example, initPQExpBuffer()
on line 92 of input.c). These are being allocated using the
malloc function used by libpq.dll. This function *may* be
different from the malloc function used by psql.exe - only
the resulting pointer must be valid. And with the default
linking methods, it *WILL* be different. Later, psql.exe
tries to free() this string, at which point it crashes
because the free() function can't find the allocated block
(it's on the allocated blocks list used by the runtime lib of
libpq.dll).Shouldn't the right thing to do be to have psql call
termPQExpBuffer() on the data instead? As it is now,
gets_fromFile() will just return the pointer received from
the PQExpBuffer.data (this may well be present at several
places - this is the one I was bitten by so far). Isn't that
kind of "accessing the internals of the PQExpBuffer
structure" wrong? Instead, perhaps it shuold make a copy of
the string, adn then termPQExpBuffer() it? In that case, the
string will have been allocated from within the same library
as the free() is called.I can get it to work just fine by doing this - changing from
(around line 100 of input.c):
if (buffer.data[buffer.len - 1] == '\n')
{
buffer.data[buffer.len - 1] = '\0';
return buffer.data;
}
to
if (buffer.data[buffer.len - 1] == '\n')
{
char *tmps;
buffer.data[buffer.len - 1] = '\0';
tmps = strdup(buffer.data);
termPQExpBuffer(&buffer);
return tmps;
}and the same a bit further down in the same function.
But, as I said above, this may be at more places in the code?
Perhaps someone more familiar to it could comment on that?What do you think shuld be done about this? Personally, I go
by the "If you allocate a piece of memory using an interface,
use the same interface to free it", but the question is how
to make it work :-)Also, AFAIK this only affects psql.exe, so the changes made
to the libpq files by this patch are required no matter how
the other issue is handled.Regards,
Magnus<<pgsql-win32.patch>>
Attachments:
pgsql-win32.patchapplication/octet-stream; name=pgsql-win32.patchDownload
diff -cr postgresql-snapshot/src/bin/psql/command.c postgresql-fixed/src/bin/psql/command.c
*** postgresql-snapshot/src/bin/psql/command.c Sun Dec 31 10:00:25 2000
--- postgresql-fixed/src/bin/psql/command.c Sat Jan 20 14:05:42 2001
***************
*** 18,23 ****
--- 18,25 ----
#include <unistd.h> /* for geteuid(), getpid(), stat() */
#else
#include <win32.h>
+ #include <io.h>
+ #include <fnctl.h>
#endif
#include "libpq-fe.h"
Only in postgresql-fixed/src/bin/psql: command.c~
diff -cr postgresql-snapshot/src/include/config.h.win32 postgresql-fixed/src/include/config.h.win32
*** postgresql-snapshot/src/include/config.h.win32 Thu Feb 24 17:02:26 2000
--- postgresql-fixed/src/include/config.h.win32 Sat Jan 20 14:05:25 2001
***************
*** 3,12 ****
*/
! /* Since we don't do autoconf, we need to read the .in file. Ugly */
! #include "version.h.in"
! #define DEF_PGPORT "5432"
#define MAXIMUM_ALIGNOF 4
#define MAXPGPATH 1024
--- 3,14 ----
*/
! #define PG_VERSION 7.1
! #define PG_VERSION_STR "7.1 (win32)"
! #define SYSCONFDIR ""
!
! #define DEF_PGPORT_STR "5432"
#define MAXIMUM_ALIGNOF 4
#define MAXPGPATH 1024
Only in postgresql-fixed/src/include: config.h.win32~
The problem is that there are strings being allocated from
libpq.dll using PQExpBuffers (for example, initPQExpBuffer()
on line 92 of input.c). These are being allocated using the
malloc function used by libpq.dll. This function *may* be
different from the malloc function used by psql.exe - only
the resulting pointer must be valid. And with the default
linking methods, it *WILL* be different. Later, psql.exe
tries to free() this string, at which point it crashes
because the free() function can't find the allocated block
(it's on the allocated blocks list used by the runtime lib of
libpq.dll).
It is possible to make the above work (at least on MSVC).
The switch is /MD that needs to be used for both the psql.exe and
libpq.dll. This forces the use of Multithreaded DLL runtime libraries.
The problem at hand is, that it uses different runtime libs for dll and exe
per default, if both use the same runtime libs it is possible to malloc in
the dll and free in the exe.
Andreas
Import Notes
Resolved by subject fallback
Magnus Hagander <mha@sollentuna.net> writes:
2) PG_VERSION is no longer defined in version.h[.in], but in
configure.in. Since we don't do configure on native win32, we
need to put it in config.h.win32 :-(
Putting
! #define PG_VERSION 7.1
! #define PG_VERSION_STR "7.1 (win32)"
into config.h.win32 is most certainly *not* an acceptable solution.
We are not going to start maintaining this file's idea of the version
by hand, now that we've centralized the version info otherwise.
Find another way.
regards, tom lane
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
It is possible to make the above work (at least on MSVC).
The switch is /MD that needs to be used for both the psql.exe and
libpq.dll. This forces the use of Multithreaded DLL runtime libraries.
I like this answer. We should be trying to make the Win32 environment
more like Unix, rather than catering to its gratuitous differences.
The malloc/free problem that Magnus discovered is certainly not the only
one, anyway. Notify processing comes to mind immediately, and who's to
say what else there may be, today or in the future? Let's solve the
problem at a systemic level, not try to patch our way to working code.
regards, tom lane
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
It is possible to make the above work (at least on MSVC).
The switch is /MD that needs to be used for both the psql.exe and
libpq.dll. This forces the use of Multithreaded DLL runtimelibraries.
I like this answer. We should be trying to make the Win32 environment
more like Unix, rather than catering to its gratuitous differences.
Definitly, me too. I'll try this as soon as I get time on it, and update my
patch with it. Unless somebody beats me to it, that is.
//Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander <mha@sollentuna.net> writes:
2) PG_VERSION is no longer defined in version.h[.in], but in
configure.in. Since we don't do configure on native win32, we
need to put it in config.h.win32 :-(Putting
! #define PG_VERSION 7.1
! #define PG_VERSION_STR "7.1 (win32)"into config.h.win32 is most certainly *not* an acceptable solution.
We are not going to start maintaining this file's idea of the version
by hand, now that we've centralized the version info otherwise.
Find another way.
I definitly did not like that either.. Hmm.
Question: Can I assume that configure.in stays the way it is now? In the way
that if I could just extract the line "VERSION='xyz'" from it, that will
continue to work? It might be possible to do something around that. If not,
then does anybody else have an idea of how to do it since autoconf won't
work?
I thought it *was* already centralised in 7.0, but back then it was in a
header file (version.h), which made it cross-platform... I'm sure there is
some advantage of having it in configure.in, but it does make it a *lot*
harder to support it on Win32, with it's very limited scripting environment
(by default).
//Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander <mha@sollentuna.net> writes:
Question: Can I assume that configure.in stays the way it is now? In the way
that if I could just extract the line "VERSION='xyz'" from it, that will
continue to work? It might be possible to do something around that.
That'd be OK with me. I don't suppose Win32 has "sed" though :-(
I thought it *was* already centralised in 7.0, but back then it was in a
header file (version.h), which made it cross-platform... I'm sure there is
some advantage of having it in configure.in, but it does make it a *lot*
harder to support it on Win32, with it's very limited scripting environment
(by default).
Actually, it might be easier to go back to keeping it in a file
version.h (NOT .in) which configure could read it out of. I never
figured out why Peter put it directly in configure.in in the first
place; that means it is actually hard-coded in two files (configure.in
and configure) which is a recipe for trouble. Peter?
regards, tom lane
Tom Lane writes:
That'd be OK with me. I don't suppose Win32 has "sed" though :-(
Cygwin does. We can worry about native support for PostgreSQL later ;-)
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Pete Forman <pete.forman@westerngeco.com> writes:
Tom Lane writes:
That'd be OK with me. I don't suppose Win32 has "sed" though :-(
Cygwin does. We can worry about native support for PostgreSQL later ;-)
This is the native support we are talking about. The Cygwin port uses
configure, no?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
Actually, it might be easier to go back to keeping it in a file
version.h (NOT .in) which configure could read it out of. I never
figured out why Peter put it directly in configure.in in the first
place; that means it is actually hard-coded in two files (configure.in
and configure) which is a recipe for trouble. Peter?
The original reason was to make it available to non-C programs.
Sure, but we can do that by having configure read the data from
version.h and insert it into wherever else it needs to be. This
puts the sed hackery into configure, which depends on sed anyway,
and not into the native-Win32 compilation process where there's
no easy way to do it.
I think you can just define it empty since the only way it will be used
(in the subset of things Win32 builds) is for psql --version output.
I don't much care for the idea of being unable to determine the version
of a Win32 psql. Psql's backslash commands are sufficiently
version-specific that you can't really treat it as being the same
across all versions.
regards, tom lane
Import Notes
Reply to msg id not found: Pine.LNX.4.30.0101221804200.1090-100000@peter.localdomainReference msg id not found: Pine.LNX.4.30.0101221804200.1090-100000@peter.localdomain | Resolved by subject fallback
Tom Lane writes:
Actually, it might be easier to go back to keeping it in a file
version.h (NOT .in) which configure could read it out of. I never
figured out why Peter put it directly in configure.in in the first
place; that means it is actually hard-coded in two files (configure.in
and configure) which is a recipe for trouble. Peter?
The original reason was to make it available to non-C programs. The
reason it was put in configure.in in particular was that the next Autoconf
upgrade would require that anyway. (Well, nothing is required, but that's
kind of the way things were supposed to work.)
I think you can just define it empty since the only way it will be used
(in the subset of things Win32 builds) is for psql --version output.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Tom Lane writes:
Putting
! #define PG_VERSION 7.1
! #define PG_VERSION_STR "7.1 (win32)"into config.h.win32 is most certainly *not* an acceptable solution.
We are not going to start maintaining this file's idea of the version
by hand, now that we've centralized the version info otherwise.
We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that thing on the
fly on Win32?
One could imagine fixing this in configure --- have configure generate
libpq.rc from libpq.rc.in, and then treat libpq.rc as part of the
distribution the same as we do for gram.c and so forth. The version
info could get substituted into config.h.win32 the same way, I suppose.
This is pretty ugly, but you could look at it as being no different
from providing gram.c for those without bison: ship those dependent
files that can't be remade without tools that may not exist on the
target platform.
You'll probably say "that's more trouble than it's worth", but version
info in a file that's only used by a marginally-supported platform is
just the kind of thing that humans will forget to update.
regards, tom lane
Tom Lane writes:
Putting
! #define PG_VERSION 7.1
! #define PG_VERSION_STR "7.1 (win32)"into config.h.win32 is most certainly *not* an acceptable solution.
We are not going to start maintaining this file's idea of the version
by hand, now that we've centralized the version info otherwise.We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Yes, I update this file for every release.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
At 13:01 22/01/01 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that thing on the
fly on Win32?
While on this subject, does anyone have a version of cygipc that works with
the current version of CygWin? What's on postgresql.org doesn't work, and
the link on the site was broken.
If I can get it working under NT4, then I can get on with JDBC testing
while the linux box is down (intalled but no networking).
Peter
On Mon, Jan 22, 2001 at 10:19:00PM +0000, Peter Mount wrote:
While on this subject, does anyone have a version of cygipc that works with
the current version of CygWin? What's on postgresql.org doesn't work, and
the link on the site was broken.
The latest cygipc distribution (source and binary) seems to be at
<http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/cygipc/index.html>.
Version 1.08 works fine for me, with the HEAD version of PostgreSQL
and DLL version 1.1.7 of cygwin.
I've been messing with ipc-daemon so that it can run as an NT service
all by itself, with no funky wrappers like 'invoker' or 'srvany'.
It's working pretty well, and even knows how to install and remove
itself as a service. I'd be happy to make the patch available if
anyone is interested in shaking it down. I plan to submit it to the
guy who's currently maintaining cygipc.
And then I'd like to get postmaster itself also running as an NT
service, able to shut down cleanly when the service is stopped.
--
Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312
Principal Consultant www.OntoSys.com fax: +1.630.879.1370
OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Quoting Fred Yankowski <fred@ontosys.com>:
On Mon, Jan 22, 2001 at 10:19:00PM +0000, Peter Mount wrote:
While on this subject, does anyone have a version of cygipc that works
with
the current version of CygWin? What's on postgresql.org doesn't work,
and
the link on the site was broken.
The latest cygipc distribution (source and binary) seems to be at
<http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/cygipc/index.html>.
Version 1.08 works fine for me, with the HEAD version of PostgreSQL
and DLL version 1.1.7 of cygwin.
Thanks, I'll see if it's going to work for me. Hopefully it's going to help
getting JDBC debugged while my Linux box is down, and also as I only have NT at
work now.
I've been messing with ipc-daemon so that it can run as an NT service
all by itself, with no funky wrappers like 'invoker' or 'srvany'.
It's working pretty well, and even knows how to install and remove
itself as a service. I'd be happy to make the patch available if
anyone is interested in shaking it down. I plan to submit it to the
guy who's currently maintaining cygipc.
I've used srvany before with cygwin. Nice little gotcha's like remembering to
mount with the -s flag etc ;-)
And then I'd like to get postmaster itself also running as an NT
service, able to shut down cleanly when the service is stopped.
Now that would be useful.
Peter
--
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Peter Eisentraut <peter_e@gmx.net> writes:
We're losing this battle anyway. Look into
src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that
thing on the fly on Win32?
It's the same thing as with version.h - e.g. not really :-( It can be done,
but I doubt it can be done cleanly.
One could imagine fixing this in configure --- have configure generate
libpq.rc from libpq.rc.in, and then treat libpq.rc as part of the
distribution the same as we do for gram.c and so forth. The version
info could get substituted into config.h.win32 the same way,
I suppose.This is pretty ugly, but you could look at it as being no different
from providing gram.c for those without bison: ship those dependent
files that can't be remade without tools that may not exist on the
target platform.You'll probably say "that's more trouble than it's worth", but version
info in a file that's only used by a marginally-supported platform is
just the kind of thing that humans will forget to update.
If it is possible to do that, then I think it would be the best. (And
putting it in both a .h and the .rc file). It wuold definitly make things
cleaner-looking for the end user :-)
I have no idea how to do this, though, so I can't submit a patch. But if
someone were to do it and tell me where/how it goes into a header, I can
update the win32 patch to work with it...
Regards,
Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander writes:
Peter Eisentraut <peter_e@gmx.net> writes:
We're losing this battle anyway. Look into
src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that
thing on the fly on Win32?It's the same thing as with version.h - e.g. not really :-( It can be done,
but I doubt it can be done cleanly.
I have no idea how to do this, though, so I can't submit a patch. But if
someone were to do it and tell me where/how it goes into a header, I can
update the win32 patch to work with it...
Since all files are now up to date for 7.1 I don't feel a lot of urge to
work on this right now. Maybe when we change this version again.
But realistically we're going to have to hand-maintain config.h.win32
anyway to account for new configure tests.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
I have added ./include/config.h.win32 to the RELEASE_CHANGES update
list.
Magnus Hagander writes:
Peter Eisentraut <peter_e@gmx.net> writes:
We're losing this battle anyway. Look into
src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that
thing on the fly on Win32?It's the same thing as with version.h - e.g. not really :-( It can be done,
but I doubt it can be done cleanly.I have no idea how to do this, though, so I can't submit a patch. But if
someone were to do it and tell me where/how it goes into a header, I can
update the win32 patch to work with it...Since all files are now up to date for 7.1 I don't feel a lot of urge to
work on this right now. Maybe when we change this version again.But realistically we're going to have to hand-maintain config.h.win32
anyway to account for new configure tests.--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Magnus, is this done?
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
It is possible to make the above work (at least on MSVC).
The switch is /MD that needs to be used for both the psql.exe and
libpq.dll. This forces the use of Multithreaded DLL runtimelibraries.
I like this answer. We should be trying to make the Win32 environment
more like Unix, rather than catering to its gratuitous differences.Definitly, me too. I'll try this as soon as I get time on it, and update my
patch with it. Unless somebody beats me to it, that is.//Magnus
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026