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

David,

On Sun, May 12, 2002 at 10:21:16AM -0400, David P. Caldwell wrote:
> 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 ...)

build.sh is not magic -- it is just how I build Cygwin PostgreSQL.
It is actually meant more to explain how I build than as a script to
use since it implicitly assumes my environment.

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

Oops! I need to add this to my README! Which I will in the next
iteration.

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

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.

> 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.) 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. I did not get any yacc errors. And the JDBC problem *may* be
caused by me doing a make distclean without having my ant environment
set first. I've done this before...

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

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

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.

> 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