Thread: Re: [PATCHES] cygwin 8.0.0beta1 postmaster/syslogger.c, port/dirmod.c,

Jason Tishler schrieb:
> On Tue, Aug 24, 2004 at 09:49:51PM +0200, Reini Urban wrote:
>>There's on remaining issue for the cygwin build:
>>../../src/port/libpgport.a(dirmod.o)(.text+0x5ee):dirmod.c: undefined
>>reference to `__imp__CurrentMemoryContext'
>>../../src/port/libpgport.a(dirmod.o)(.text+0x64b):dirmod.c: undefined
>>reference to `__imp__CurrentMemoryContext'
>
>
> Note I have no experience with 8.0 so the following is a WAG...
> The above is likely caused by not linking against an import library
> (i.e., libpostgres.a).

Yes, it is defined in libpostgres.a. Hmm, a cross-dependency problem in
the Makefile. With an added -lpostgres postgres.exe builds fine.
But I'll try to add the single object file only where it is defined.

I also see that it is still linking against cygipc.
LIBS=-lintl -lssl -lcrypto -lz -lreadline -lcygipc -lcrypt -lresolv -lm

Do we still need this? As I see it, pgsql has its own ipc mechanism.
Without -lcygipc it also builds fine. ...

 >I'm quite willing to help to ensure a smooth transition and to help
 >minimize your "pain." :,)  Maybe 8.0 can be a joint effort, with you
 >taking over fully with 8.0.x or 8.1?

Sure, why not?
But I'm also trying to build the 7.4.5 now, because I want to see the
changes in the new 8 branch. So you can sit and have a rest. :)

 From another thread...
 > Is "--with-template=cygwin" required?  It wasn't before.

Yes, this is apparently new for 8.x.
And it does help to be precise in the configure line.

BTW: I will convert your build.sh to the cygwin generic-build-script
system. This is much easier.

 > Does "--with-tcl" no longer build cleanly?

This wasn't in your 7.4.3 build.sh included and I didn't install the
tcl/tk sources (only under my perltk tree). But I can have a try.

I have tclsh, the headers and the libs, just a tclConfig.sh script is
missing from the cygwin build. Should not be that hard. All the libs and
includes are at the standard paths.

I'll finish the 8.0.0-beta1 port to cygwin, and post to the patches list
then the cumulative patches. Questions to pgsql-hackers or pgsql-cygwin?

The 8.x build is almost okay now. Just a remaining libreadline issue in
src/bin/psql/tab-complete.c
And testing.

And sockets would also be fine.
$ postgresql-8.0.0beta1-1/src/backend/postgres.exe
FATAL:  unrecognized configuration parameter "tcpip_socket"
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini,

On Wed, Aug 25, 2004 at 01:12:46AM +0200, Reini Urban wrote:
> Jason Tishler schrieb:
> >On Tue, Aug 24, 2004 at 09:49:51PM +0200, Reini Urban wrote:
> >>There's on remaining issue for the cygwin build:
> >>../../src/port/libpgport.a(dirmod.o)(.text+0x5ee):dirmod.c: undefined
> >>reference to `__imp__CurrentMemoryContext'
> >>../../src/port/libpgport.a(dirmod.o)(.text+0x64b):dirmod.c: undefined
> >>reference to `__imp__CurrentMemoryContext'
> >
> >Note I have no experience with 8.0 so the following is a WAG...
> >The above is likely caused by not linking against an import library
> >(i.e., libpostgres.a).
>
> Yes, it is defined in libpostgres.a. Hmm, a cross-dependency problem in
> the Makefile. With an added -lpostgres postgres.exe builds fine.

In previous versions, postgres.exe built fine without -lpostgres.  Other
components needed to link with libpostgres.a -- not postgres.exe.  As
you indicated above, seems like there is a cross-dependency issue
introduced in 8.0.

> But I'll try to add the single object file only where it is defined.

IMO, linking against libpostgres.a is preferable assuming the
cross-dependency issue cannot be solved.

> I also see that it is still linking against cygipc.
> LIBS=-lintl -lssl -lcrypto -lz -lreadline -lcygipc -lcrypt -lresolv -lm

The shouldn't happen.  Do you have cygipc installed?  If so, then
uninstall and try again.  Any better?

> Do we still need this?

AFAICT, no.

> As I see it, pgsql has its own ipc mechanism.

Does the above imply that 8.0 will not need the IPC in cygserver?

> Without -lcygipc it also builds fine. ...

Yes.  For example, 7.4.3 build fine against cygserver.

> >I'm quite willing to help to ensure a smooth transition and to help
> >minimize your "pain." :,)  Maybe 8.0 can be a joint effort, with you
> >taking over fully with 8.0.x or 8.1?
>
> Sure, why not?

Thanks!

> But I'm also trying to build the 7.4.5 now, because I want to see the
> changes in the new 8 branch. So you can sit and have a rest. :)

Thanks again.  I can use the rest. :,)

> From another thread...
> > Is "--with-template=cygwin" required?  It wasn't before.
>
> Yes, this is apparently new for 8.x.

OK, I was just surprised that configure didn't automatically detect the
platform.

> And it does help to be precise in the configure line.

Precise is good -- redundant is not necessarily good.

> BTW: I will convert your build.sh to the cygwin generic-build-script
> system. This is much easier.

OK.

> > Does "--with-tcl" no longer build cleanly?
>
> This wasn't in your 7.4.3 build.sh included and I didn't install the
> tcl/tk sources (only under my perltk tree).

Sorry, for the above.  I temporarily forgot that Cygwin PostgreSQL has
TCL issues.

> But I can have a try.

OK, but IMO I would address the other issues first since Cygwin
PostgreSQL never supported TCL in the past.  BTW, check the archives,
Patrick Samson and I have made some progress in the past.

> I have tclsh, the headers and the libs, just a tclConfig.sh script is
> missing from the cygwin build. Should not be that hard. All the libs and
> includes are at the standard paths.

It may be harder than anticipated -- remember the Cygwin Tcl/Tk package
is really a native Win32 package not a Cygwin one... :,(

> I'll finish the 8.0.0-beta1 port to cygwin,

Thanks.

> and post to the patches list then the cumulative patches

Sounds good.

> Questions to pgsql-hackers or pgsql-cygwin?

Depends on the question. :,)

> The 8.x build is almost okay now. Just a remaining libreadline issue in
> src/bin/psql/tab-complete.c
> And testing.

Let me know how is goes.

> And sockets would also be fine.
> $ postgresql-8.0.0beta1-1/src/backend/postgres.exe
> FATAL:  unrecognized configuration parameter "tcpip_socket"

See the following:

    http://archives.postgresql.org/pgsql-general/2004-08/msg01181.php

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Attached is my 7.4.5 build script,
not yet converted to the new generic-build-script mechanism.

In order to fix the tcl issues I needed perl.
There are still minor tcl issues, but I'll fix them soon.

There's another short Makefile.cygwin patch to build contrib/dbase
correctly. Hope this will be accepted (or looked at) upstream.
With the standard order of libs from configure it will fail, because our
libiconv is shared.
With just the needed libs in the correct order it builds fine:
$ gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations dbf.o dbf2pg.o endian.o -lpq -L../../src/port
-lpgport -lintl -o dbf2pg

*************************

The first standard regression test attempt (--max-connections=10) failed
with:

creating template1 database in
/usr/src/postgresql/postgresql-7.4.5-1/src/test/regress/./tmp_check/data/base/1...
FATAL:  could not create shared memory segment: Function not implemented
DETAIL:  Failed system call was shmget(key=1, size=1081344, 03600).

Seems to be a cygserver issue. cygserver is running as service.
I'll hunt that down, but looks strange. Seems that I really linked
against cygipc and so it doesn't use cygserver :(

$ tmp_check/install/usr/bin/initdb -D "tmp_check/data" -L
tmp_check/install/usr/share/postgresql --debug --no-locale -E Latin1

creating template1 database in tmp_check/data/base/1... DEBUG:  invoking
IpcMemoryCreate(size=1081344)
FATAL:  could not create shared memory segment: Function not implemented
DETAIL:  Failed system call was shmget(key=1, size=1081344, 03600).


Jason Tishler schrieb:
> On Wed, Aug 25, 2004 at 01:12:46AM +0200, Reini Urban wrote:
>
>>Jason Tishler schrieb:
>>
>>>On Tue, Aug 24, 2004 at 09:49:51PM +0200, Reini Urban wrote:
>>>
>>>>There's on remaining issue for the cygwin build:
>>>>../../src/port/libpgport.a(dirmod.o)(.text+0x5ee):dirmod.c: undefined
>>>>reference to `__imp__CurrentMemoryContext'
>>>>../../src/port/libpgport.a(dirmod.o)(.text+0x64b):dirmod.c: undefined
>>>>reference to `__imp__CurrentMemoryContext'
>>>
>>>Note I have no experience with 8.0 so the following is a WAG...
>>>The above is likely caused by not linking against an import library
>>>(i.e., libpostgres.a).
>>
>>Yes, it is defined in libpostgres.a. Hmm, a cross-dependency problem in
>>the Makefile. With an added -lpostgres postgres.exe builds fine.
>
>
> In previous versions, postgres.exe built fine without -lpostgres.  Other
> components needed to link with libpostgres.a -- not postgres.exe.  As
> you indicated above, seems like there is a cross-dependency issue
> introduced in 8.0.

It's just one simple backend object file, so I'll try to hunt that down
later. So the developers can fix their Makefile also.

>>But I'll try to add the single object file only where it is defined.
>
>
> IMO, linking against libpostgres.a is preferable assuming the
> cross-dependency issue cannot be solved.
>
>
>>I also see that it is still linking against cygipc.
>>LIBS=-lintl -lssl -lcrypto -lz -lreadline -lcygipc -lcrypt -lresolv -lm
>
>
> The shouldn't happen.  Do you have cygipc installed?  If so, then
> uninstall and try again.  Any better?

That is probably some left-over autoconf issue.

>>Do we still need this?
>
> AFAICT, no.
>
>
>>As I see it, pgsql has its own ipc mechanism.
> Does the above imply that 8.0 will not need the IPC in cygserver?

Looks like so, but I'll check later. First I want to finish 7.4.5
because of the pending perl problems.

>>Without -lcygipc it also builds fine. ...
>
> Yes.  For example, 7.4.3 build fine against cygserver.
>
>
>>>I'm quite willing to help to ensure a smooth transition and to help
>>>minimize your "pain." :,)  Maybe 8.0 can be a joint effort, with you
>>>taking over fully with 8.0.x or 8.1?
>>
>>Sure, why not?
>
>
> Thanks!
>
>
>>But I'm also trying to build the 7.4.5 now, because I want to see the
>>changes in the new 8 branch. So you can sit and have a rest. :)
>
>
> Thanks again.  I can use the rest. :,)
>
>
>>From another thread...
>>
>>>Is "--with-template=cygwin" required?  It wasn't before.
>>
>>Yes, this is apparently new for 8.x.
>
>
> OK, I was just surprised that configure didn't automatically detect the
> platform.
>
>
>>And it does help to be precise in the configure line.
>
>
> Precise is good -- redundant is not necessarily good.
>
>
>>BTW: I will convert your build.sh to the cygwin generic-build-script
>>system. This is much easier.
>
>
> OK.
>
>
>>>Does "--with-tcl" no longer build cleanly?
>>
>>This wasn't in your 7.4.3 build.sh included and I didn't install the
>>tcl/tk sources (only under my perltk tree).
>
>
> Sorry, for the above.  I temporarily forgot that Cygwin PostgreSQL has
> TCL issues.
>
>
>>But I can have a try.
>
>
> OK, but IMO I would address the other issues first since Cygwin
> PostgreSQL never supported TCL in the past.  BTW, check the archives,
> Patrick Samson and I have made some progress in the past.
>
>
>>I have tclsh, the headers and the libs, just a tclConfig.sh script is
>>missing from the cygwin build. Should not be that hard. All the libs and
>>includes are at the standard paths.
>
>
> It may be harder than anticipated -- remember the Cygwin Tcl/Tk package
> is really a native Win32 package not a Cygwin one... :,(
>
>
>>I'll finish the 8.0.0-beta1 port to cygwin,
>
>
> Thanks.
>
>
>>and post to the patches list then the cumulative patches
>
>
> Sounds good.
>
>
>>Questions to pgsql-hackers or pgsql-cygwin?
>
>
> Depends on the question. :,)
>
>
>>The 8.x build is almost okay now. Just a remaining libreadline issue in
>>src/bin/psql/tab-complete.c
>>And testing.
>
>
> Let me know how is goes.

Uh, this was my old readline lib leftover in /usr/local/lib
It builds fine now.

>>And sockets would also be fine.
>>$ postgresql-8.0.0beta1-1/src/backend/postgres.exe
>>FATAL:  unrecognized configuration parameter "tcpip_socket"
>
>
> See the following:
>
>     http://archives.postgresql.org/pgsql-general/2004-08/msg01181.php

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
#! /bin/bash

# $Id: build.sh,v 1.19 2004/01/09 15:18:13 jt Exp $

# vim: tabstop=4

# usage: CYGWIN-PATCHES/build.sh 7.4.5 1

# parse arguments
version=$1
port=$2

# constants
pkg=postgresql

# dir variables
Prefix=/usr
TmpDir=/tmp/$pkg.$$
InstallPrefix=$TmpDir$Prefix

DataDir=$InstallPrefix/share
BinDir=$InstallPrefix/bin
LibDir=$InstallPrefix/lib
ManDir=$DataDir/man
DocDir=$DataDir/doc/$pkg-$version
CygDocDir=$DataDir/doc/Cygwin
PatchDir=CYGWIN-PATCHES
SrcDocDir=doc

# you might have to add these
# special tkConfig.sh 8.4 fixes (the tcltk maintainer should really fix these paths)
# but you can also fix them in /usr/lib/t(k|cl)Config.sh
# with perl -pi.orig -e's|/cygnus/netrel/build|/usr/src|; s|/netrel/src|/usr/src|;' /usr/lib/tkConfig.sh
/usr/lib/tclConfig.sh
# mounting them is not that good...
#UsrSrcMount="`cygpath -w /usr/src`"
#mount -f -u -b "$UsrSrcMount" "/cygnus/netrel/build"
#mount -f -u -b "$UsrSrcMount" "/netrel/src"
if [ ! -d /usr/src/libtcltk ]; then
  if [ -d /usr/src/tcltk-20030901-1 ]; then
    ln -s /usr/src/tcltk-20030901-1 /usr/src/libtcltk
    withTcl="--with-tcl --with-tclconfig=/usr/lib --with-tkconfig=/usr/lib"
    echo "src package tcltk-20030901-1 found. will build --with-tcl"
  else
    echo "src package at /usr/src/tcltk-20030901-1 not found. will not build --with-tcl"
    withTcl=
  fi
else
  withTcl="--with-tcl --with-tclconfig=/usr/lib --with-tkconfig=/usr/lib"
  echo "src package libtcltk found. will build --with-tcl"
fi

# not yet ready for primetime
withTcl=

# configure
./configure --with-template=cygwin --enable-integer-datetimes --enable-nls --enable-multibyte --with-python --with-perl
--with-java--with-CXX --with-openssl $withTcl --prefix=$Prefix --sysconfdir=/etc --datadir=/usr/share
--mandir=/usr/share/man--docdir=$Prefix/share/doc/$pkg-$version 

# patch the wrong cygwin tcltk paths
if [ ! -z $withTcl ]; then
  perl -pi.orig -e's|/cygnus/netrel/build|/usr/src|; s|/netrel/src|/usr/src|;' src/Makefile.global
  # perl -pi.orig -e"s|TCL_LIBS=''|TCL_LIBS='-ltcl'|;" src/
fi
# patch Makefile.cygwin
patch -p0 <<EOF

--- src/makefiles/Makefile.cygwin.orig  2003-05-22 18:20:44.000000000 +0100
+++ src/makefiles/Makefile.cygwin       2004-08-25 14:26:18.076225800 +0100
@@ -32,6 +32,17 @@
 override CPPFLAGS+= -DUSE_DL_IMPORT
 endif

+ifneq (,$(findstring tcl,$(subdir)))
+override TCL_LIB_SPEC += -ltcl84
+override TK_LIBS += -ltk
+override TK_LIB_SPEC += -ltcl84
+endif
+
+ifneq (,$(findstring contrib/dbase,$(subdir)))
+override PG_LIBS = -lpq
+override LIBS = -lpgport -lintl
+endif
+
 override javadir := '$(shell cygpath -w $(javadir))'

 sqlmansect = 7
EOF


# make
make
make -C contrib

# make install
make DESTDIR=$TmpDir install
make DESTDIR=$TmpDir install-all-headers
make -C contrib DESTDIR=$TmpDir install

# strip executables and DLLs
find $InstallPrefix -name '*.exe' -o -name '*.dll' | xargs strip

# move DLLs from lib to bin
mv $LibDir/*.dll $BinDir

# copy libpostgres.a to lib (FIXME: temporary hack)
cp src/backend/libpostgres.a $LibDir

# create man cat dirs
mkdir $ManDir/cat1 $ManDir/catl

# convert doc symlinks into "hard" links
find $DocDir -type l | xargs -r ls -l | gawk '{i = NF - 2; print $i, $NF}' |
while read link file
do
    path=$(dirname $link)
    rm -f $link
    ln $path/$file $link
done

# copy Cygwin PostgreSQL README file
mkdir -p $CygDocDir
cp $PatchDir/README $CygDocDir/$pkg-$version.README

# copy PostgreSQL COPYRIGHT, README, etc. files
TopFiles=(COPYRIGHT HISTORY INSTALL README)
DocFiles=(FAQ FAQ_MSWIN KNOWN_BUGS MISSING_FEATURES README.mb.big5 \
    README.mb.jp bug.template)
cp ${TopFiles[*]} ${DocFiles[*]/#/$SrcDocDir/} $DocDir

# create package
tar -C $TmpDir -cjf $pkg-$version-$port.tar.bz2 usr

# remove temporary directory
rm -fr $TmpDir

# remove temporary tk mounts
#umount /cygnus/netrel/build
#umount /netrel/src

Reini,

On Wed, Aug 25, 2004 at 04:13:29PM +0200, Reini Urban wrote:
> Attached is my 7.4.5 build script,
> not yet converted to the new generic-build-script mechanism.
>
> In order to fix the tcl issues I needed perl.
> There are still minor tcl issues, but I'll fix them soon.

IMO, I would hold off on Tcl until 8.0 in order to get 7.4.5 out ASAP.

> There's another short Makefile.cygwin patch to build contrib/dbase
> correctly. Hope this will be accepted (or looked at) upstream.

Sending patches to pgsql-patches@ is a better way to get noticed. :,)

> With the standard order of libs from configure it will fail, because
> our libiconv is shared.
> With just the needed libs in the correct order it builds fine:
> $ gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations dbf.o dbf2pg.o endian.o -lpq -L../../src/port
> -lpgport -lintl -o dbf2pg

dbf2pg from 7.4.3 built cleanly for me:

    gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations dbf.o dbf2pg.o endian.o
-L../../src/interfaces/libpq-lpq -L../../src/port -L/usr/local/lib  -lssl -lcrypto -lz -lreadline -lcrypt -lpgport -o
dbf2pg

Why is it failing for you?

> The first standard regression test attempt (--max-connections=10)
> failed with:

I recommend using the following:

    make MAX_CONNECTIONS=1 check

I certainly wouldn't use MAX_CONNECTIONS > 5 as indicated in the README.

> [snip]
> Seems to be a cygserver issue. cygserver is running as service.  I'll
> hunt that down, but looks strange. Seems that I really linked against
> cygipc and so it doesn't use cygserver :(

Hmm...  What does cygcheck indicate?

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

ok, postgresql-7.4.5-1 is ready.

The problems were cygipc related (of course), which I
patched away in configure.

All tests passed ok (besides one minor cr/lf issue. see attached)

The files are at
http://xarch.tu-graz.ac.at/home/rurban/software/cygwin/postgresql/postgresql-7.4.5-1/

just the setup.hint is missing. This is your (Jason) job :)

The src package is similar to your old setup,
   (orisrc/ plus orisrc/CYGWIN-PATCHES/)
but it really should be changed to
<orisrc>.tar.bz2 and the build and patch file.

I'll to change that with the 8.0.0beta1 package.


Jason Tishler schrieb:
> On Wed, Aug 25, 2004 at 04:13:29PM +0200, Reini Urban wrote:
>
>>Attached is my 7.4.5 build script,
>>not yet converted to the new generic-build-script mechanism.
>>
>>In order to fix the tcl issues I needed perl.
>>There are still minor tcl issues, but I'll fix them soon.
>
> IMO, I would hold off on Tcl until 8.0 in order to get 7.4.5 out ASAP.
>
>
>>There's another short Makefile.cygwin patch to build contrib/dbase
>>correctly. Hope this will be accepted (or looked at) upstream.
>
>
> Sending patches to pgsql-patches@ is a better way to get noticed. :,)

ok, I'll do.

>>With the standard order of libs from configure it will fail, because
>>our libiconv is shared.
>>With just the needed libs in the correct order it builds fine:
>>$ gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
>>-Wmissing-declarations dbf.o dbf2pg.o endian.o -lpq -L../../src/port
>>-lpgport -lintl -o dbf2pg
>
>
> dbf2pg from 7.4.3 built cleanly for me:
>
>     gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations dbf.o dbf2pg.o endian.o
-L../../src/interfaces/libpq-lpq -L../../src/port -L/usr/local/lib  -lssl -lcrypto -lz -lreadline -lcrypt -lpgport -o
dbf2pg
>
> Why is it failing for you?

Because a had -lintl also, which is dynamically resolved.
your built doesn't use libintl.
I wanted to have nls support. :)

>>The first standard regression test attempt (--max-connections=10)
>>failed with:
>
>
> I recommend using the following:
>
>     make MAX_CONNECTIONS=1 check
>
> I certainly wouldn't use MAX_CONNECTIONS > 5 as indicated in the README.
>
>
>>[snip]
>>Seems to be a cygserver issue. cygserver is running as service.  I'll
>>hunt that down, but looks strange. Seems that I really linked against
>>cygipc and so it doesn't use cygserver :(
>
> Hmm...  What does cygcheck indicate?

The problem was this autoconf line (configure.in):
AC_CHECK_LIB(cygipc, shmget)

we have now "native" cygwin shmget support. so this check is bogus.
we really should add a check if shmget is in sys/shm.h
something like
AC_CHECK_LIB(, shmget)

(untested)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
*** ./expected/horology-no-DST-before-1970.out    Thu Sep 25 17:16:34 2003
--- ./results/horology.out    Wed Aug 25 18:33:14 2004
***************
*** 1787,1796 ****
       | Wed Mar 15 13:14:02 2000 PST | @ 34 years                    | Tue Mar 15 13:14:02 1966 PST
       | Sun Dec 31 17:32:01 2000 PST | @ 34 years                    | Sat Dec 31 17:32:01 1966 PST
       | Mon Jan 01 17:32:01 2001 PST | @ 34 years                    | Sun Jan 01 17:32:01 1967 PST
!      | Sat Sep 22 18:19:20 2001 PDT | @ 34 years                    | Fri Sep 22 18:19:20 1967 PST
!      | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours             | Thu Jul 31 12:00:00 1969 PST
!      | Thu Jan 01 00:00:00 1970 PST | @ 5 mons                      | Fri Aug 01 00:00:00 1969 PST
!      | Thu Jan 01 00:00:00 1970 PST | @ 3 mons                      | Wed Oct 01 00:00:00 1969 PST
       | Thu Jan 01 00:00:00 1970 PST | @ 10 days                     | Mon Dec 22 00:00:00 1969 PST
       | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST
       | Thu Jan 01 00:00:00 1970 PST | @ 5 hours                     | Wed Dec 31 19:00:00 1969 PST
--- 1787,1796 ----
       | Wed Mar 15 13:14:02 2000 PST | @ 34 years                    | Tue Mar 15 13:14:02 1966 PST
       | Sun Dec 31 17:32:01 2000 PST | @ 34 years                    | Sat Dec 31 17:32:01 1966 PST
       | Mon Jan 01 17:32:01 2001 PST | @ 34 years                    | Sun Jan 01 17:32:01 1967 PST
!      | Sat Sep 22 18:19:20 2001 PDT | @ 34 years                    | Fri Sep 22 18:19:20 1967 PDT
!      | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours             | Thu Jul 31 12:00:00 1969 PDT
!      | Thu Jan 01 00:00:00 1970 PST | @ 5 mons                      | Fri Aug 01 00:00:00 1969 PDT
!      | Thu Jan 01 00:00:00 1970 PST | @ 3 mons                      | Wed Oct 01 00:00:00 1969 PDT
       | Thu Jan 01 00:00:00 1970 PST | @ 10 days                     | Mon Dec 22 00:00:00 1969 PST
       | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST
       | Thu Jan 01 00:00:00 1970 PST | @ 5 hours                     | Wed Dec 31 19:00:00 1969 PST

======================================================================

Reini,

On Wed, Aug 25, 2004 at 08:09:26PM +0200, Reini Urban wrote:
> ok, postgresql-7.4.5-1 is ready.

Thanks, but I'm going to upload a postgresql-7.4.5-1 shortly.  Let's
transition maintainership in the 8.0 time frame.

> The problems were cygipc related (of course), which I patched away in
> configure.

AFAICT, there should not be any cygipc problems as long as it is not
installed on the build system.

> All tests passed ok (besides one minor cr/lf issue. see attached)

horology fails for me too, but the failure is due to daylight saving
issues (i.e., PDT vs. PST) not a textmode issue.

> just the setup.hint is missing. This is your (Jason) job :)

The setup.hint already on sources does not require any updating.

> The src package is similar to your old setup,
>   (orisrc/ plus orisrc/CYGWIN-PATCHES/)
> but it really should be changed to
> <orisrc>.tar.bz2 and the build and patch file.
>
> I'll to change that with the 8.0.0beta1 package.

The above is fine -- just call me old fashioned... :,)

> Jason Tishler schrieb:
> >Hmm...  What does cygcheck indicate?
>
> The problem was this autoconf line (configure.in):
> AC_CHECK_LIB(cygipc, shmget)
>
> we have now "native" cygwin shmget support. so this check is bogus.
> we really should add a check if shmget is in sys/shm.h
> something like
> AC_CHECK_LIB(, shmget)

AFAICT, the above change is not necessary:

    checking for shmget in -lcygipc... no
    ...
    checking sys/ipc.h usability... yes
    checking sys/ipc.h presence... yes
    checking for sys/ipc.h... yes

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Jason Tishler schrieb:
> On Wed, Aug 25, 2004 at 08:09:26PM +0200, Reini Urban wrote:
>>ok, postgresql-7.4.5-1 is ready.
>
> Thanks, but I'm going to upload a postgresql-7.4.5-1 shortly.  Let's
> transition maintainership in the 8.0 time frame.

Super. So I can check tcl also.

Please also check my version of the cygwin README.
I added a "Whats new" section.

The new native win32 server is very good, but the cygwin port is much
more compatible to the unix version, and most people will prefer cygwin
as development platform. Just to test it.

> AFAICT, the above change is not necessary:
>
>     checking for shmget in -lcygipc... no
>     ...
>     checking sys/ipc.h usability... yes
>     checking sys/ipc.h presence... yes
>     checking for sys/ipc.h... yes

The problem is, that I still have cygipc installed, so it will find it,
even if cygserver is running.
Others maybe also. Call it defensive programming.

Anyway my postgresql-7.4.5-1 cygipc configure.in patch is pending, and
will be useful for the 8 series also.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini,

On Thu, Aug 26, 2004 at 06:59:24PM +0200, Reini Urban wrote:
> Jason Tishler schrieb:
> >On Wed, Aug 25, 2004 at 08:09:26PM +0200, Reini Urban wrote:
> >>ok, postgresql-7.4.5-1 is ready.
> >
> >Thanks, but I'm going to upload a postgresql-7.4.5-1 shortly.  Let's
> >transition maintainership in the 8.0 time frame.
>
> Super. So I can check tcl also.

Please do.  Building with Tcl is only the first step, I never got PL/Tcl
to work.

> Please also check my version of the cygwin README.  I added a "Whats
> new" section.

Will do.

> >AFAICT, the above change is not necessary:
> >
> >    checking for shmget in -lcygipc... no
> >    ...
> >    checking sys/ipc.h usability... yes
> >    checking sys/ipc.h presence... yes
> >    checking for sys/ipc.h... yes
>
> The problem is, that I still have cygipc installed, so it will find
> it, even if cygserver is running.  Others maybe also. Call it
> defensive programming.

If you are going to maintain Cygwin PostgreSQL, then I highly recommend
uninstalling the deprecated cygipc package.

> Anyway my postgresql-7.4.5-1 cygipc configure.in patch is pending, and
> will be useful for the 8 series also.

AFAICT, your configure.in patch has been rejected.  Sorry, but I have to
agree with Peter.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6