Re: rename() vs. link(); building from source - Mailing list pgsql-cygwin

From David P. Caldwell
Subject Re: rename() vs. link(); building from source
Date
Msg-id JIEPJODHFFPGJDGMCPBEGEMEDIAA.inonit@inonit.com
Whole thread Raw
In response to Re: rename() vs. link(); building from source  (Barry Pederson <bp@barryp.org>)
Responses Re: rename() vs. link(); building from source
List pgsql-cygwin
Barry:

Thanks!

As for the general interest stuff:

To continue the blow-by-blow, I used the Cygwin installer to get the latest
source, and it contained the extra directory as promised.

I was surprised when I examined it ... the script didn't seem to be doing
anything magical that I wasn't.  (Run configure, run make ...)

At first, I was unable to use build.sh to build because I didn't have ant
installed and/or set up.  After downloading, setting the JAVA_HOME and
ANT_HOME variables, and adding ANT_HOME/bin to the path, that worked.

The next problem I ran into had to do with Python.  Unfortunately, I never
solved it (see below), so I don't know exactly what caused it.  At the time
that build.sh was running, it was detecting Python 2.1, correctly.
 (python -V gave "2.1.1" or something).  However, there was no
/usr/include/python2.1, only /usr/include/python2.2, on my system.  I tried
my symlink trick to get it to work, but there are apparently
incompatibilities between the headers or libraries, because it still blew up
with undefined something or other (I wish I had saved the error message).  I
downgraded to python2.1 through the installer, but that didn't fix it
either, then upgraded to 2.2, and that didn't do it either.  I gave up at
that point.

Seeing that the build.sh script was rather simple, I decided to return to
the CVS snapshot I had gotten from postgresql.org.  I figured that would be
superior from an administration point of view anyway, because CVS would make
it easier for me to deal with patches, etc.  I also decided to go with
minimalist options, so I just ran configure --enable-multibyte --with-java.

I noticed that running build.sh did not exhibit the error I complained about
in my earlier E-mail (with some yacc error), so it occurred to me to check
the source for that file in CVS.  Sure enough, it had been updated since
7.2.1 ... so I think I can report that the current development tree doesn't
build on Cygwin for that reason.  (Having run both builds, I also notice
that someone has been going through and fixing lots of bison warnings, so
the error was probably introduced then.)  I grabbed the 7.2.1 release from
CVS instead (somewhat counterintuitively tagged REL7_2_STABLE rather than
REL7_2_1).

At that point, I had some readline problems (unresolved symbols), so I
downgraded my readline to 4.2-3 from 4.2a-1.  That didn't work, so I
re-upgraded to 4.2a-1 and ran make again ... and it worked!  No explanation
for how that happened, though I notice now there are separate libreadline4
and libreadline5 packages in addition, so maybe there are some complexities
involved that I don't fully grasp.

Finally, I edited my source file, ran make again, and everything is fine.
Here's the diff:

Index: xlog.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.86.2.1
diff -r1.86.2.1 xlog.c
1509c1509
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__) && !defined(N_PLAT_NLM)

I added the !defined(N_PLAT_NLM) because that's been added to the source
tree since 7.2.1, to support NetWare (according to the CVS log message).

Anyway, thanks to Barry again for the help, and I hope something from this
narrative helps someone else at some point.  I apologize for not documenting
the steps better ... I should have been focusing on keeping a log, but I got
impatient.

-- David.

-----Original Message-----
From: Barry Pederson [mailto:bp@barryp.org]
Sent: Sunday, May 12, 2002 12:25 AM
To: David P. Caldwell
Cc: pgsql-cygwin@postgresql.org
Subject: Re: [CYGWIN] rename() vs. link(); building from source


David P. Caldwell wrote:
>
> I did find the /usr/doc/Cygwin/postgresql-7.2.README ... I was intrigued
by
> the section "Source."  I figured that some combination of build.sh, etc.,
> would do it for me ... the file says PostgreSQL builds out of the box with
a
> perl-related caveat and I wasn't going to build perl, so I was hopeful.  I
> was even more excited by:
>
> See CYGWIN-PATCHES/build.sh in the source archive for my exact build
> recipe for configuring, making, and packaging this distribution.
>
> However, try as I might, I can't figure out what that refers to.  I've
> looked under both the PostgreSQL source tree (thoroughly) and the Cygwin
> source tree (not as thoroughly), done net searches, and can't find any
> matches for "CYGWIN-PATCHES" ... so I'm stuck there for the moment.

If install the PostgreSQL source by way of the Cygwin installer, you should
find the CYGWIN-PATCHES directory in a /usr/src/postgresql-7.2.1-1 directory

IIRC, all you have to do to build (assuming you have all other necessary
cygwin packages installed - gcc, etc) is cd to the above mentioned directory
and run: CYGWIN-PATCHES/build.sh 7.2.1 1

(those last 2 params are the version and port number, which the build.sh
expects as arguments, I don't recall offhand exactly why, but things seemed
to
go smoother later on if I kept the same port number as what the -real-
cygwin
postgresql package was)

When I tried it (to do the unlink/rename change), I tweaked the build.sh
line
27 to remove --with-perl and --with-python from the configure args.  Other
than that, it built out-of-the-box pretty much as advertised (and the
recycling transaction logs problem went away in my case).

    Barry


pgsql-cygwin by date:

Previous
From: Jason Tishler
Date:
Subject: Re: plpgsql.dll path
Next
From: "David P. Caldwell"
Date:
Subject: Re: rename() vs. link(); building from source