Thread: 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
> -----Original Message-----
> From: Magnus Hagander
> Sent: den 20 januari 2001 14:29
> To: 'pgsql-hackers@postgresql.org'
> Subject: Postgresql on win32
>
> Hello!
>
> 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_STR
>
> I 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>>
Attachment
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
> 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
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
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/
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
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, Pennsylvania19026
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
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, Pennsylvania19026