Re: rename() vs. link(); building from source

Jason:

>Cygwin PostgreSQL should build against Python 2.2 see the following:
>
> http://sources.redhat.com/ml/cygwin-announce/2002/msg00048.html
>
>Additionally, it was built against Python 2.1.1 in the past too. I'm not
>sure why you are having problems.

Me neither. :) The patched version of the source that I've built now
doesn't include Python, Perl, or CXX interface. Don't know if this affects
anything below.

>> I grabbed the 7.2.1 release from
>> CVS instead (somewhat counterintuitively tagged REL7_2_STABLE rather than
>> REL7_2_1).

>I just did a cvs update and was able to build everything but the JDBC
>driver.

One other caveat that may be README-worthy is that if you are running JDK
1.4, the script tries to build against the new JDBC 3.0 classes now included
as part of J2SE, and fails (there are a bunch of new methods that aren't
implemented in the driver). I pointed my JAVA_HOME to JDK 1.3 in order to
get it to work.

>I did not get any yacc errors.

As for the other stuff, yeah, I'm not sure. I've had lots of mysterious
occurrences (to me) in the course of the last couple of days (but see
below).

> 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!

One issue that occurs to me is that I did *not* remove the binary version of
PostgreSQL when building my version. Combined with the fact that /bin is
(duh) in my path, this may have caused all sorts of confusion vis-a-vis
linking, etc. This may explain why uninstalling and reinstalling random
programs (like readline) fixed some of my problems, by causing programs to
be relinked. I now have removed the PostgreSQL package, so things may go
differently (hopefully better) for me if I try to build from the current CVS
tree.

>Adding "!defined(N_PLAT_NLM)" is good, but generate a unified or context
>diff with the "-u" or "-c" option instead. Please submit this patch
>to pgsql-patches.

Lucky for you I just learned about diff last week. Otherwise, I'd be
mystified. :)

>After some reflection, I would appreciate if either you or Barry submit
>the patch. This is because you can reproduce the problem and hence
>prove that the patch fixes it. Would you be willing to submit it?

Well, I'd be willing if Barry's not :). Seriously, it sounds like he's got
an easier reproduction case than mine. I can reproduce the problem at will,
but my case is not something I could submit along with the patch. I've just
run a small test case that worked fine, but I'm not quite to the point of
signing off on it -- my test case took about 30-60 minutes to blow up,
usually.

In addition, I'm a little terrified of disturbing my newly stable system,
since I feel like some luck was involved in getting it built. I'll be
willing to (carefully) mess with it if Barry's not. Barry? Please? :)

-- David.

-----Original Message-----
From: Jason Tishler [mailto:jason(at)tishler(dot)net]
Sent: Sunday, May 12, 2002 4:52 PM
To: David P. Caldwell
Cc: bp(at)barryp(dot)org; pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] rename() vs. link(); building from source

> 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.

Building CVS is the best -- especially it you are going to submit a patch.
After some reflection, I would appreciate if either you or Barry submit
the patch. This is because you can reproduce the problem and hence
prove that the patch fixes it. Would you be willing to submit it?

> 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.)

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.

Hmm...I don't know why you are having problems with readline too. Note
that I submitted a patch to PostgreSQL CVS that was accepted a while ago
so the source should be good to go regarding readline.

> 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.

No problem -- I have been guilty of the above many times myself. Thanks
for your time.

Jason