Thread: 7.1 RC1 RPM

Any change of getting a 7.1 RC1 RPM? I'm using the beta4 RPMs at the moment
but don't seem to be any more recent ones.

It would seem dangerous to me to produce a 7.1 RPM without testing the RPM
build process?

-mike

Mike Cannon-Brookes wrote:
> 
> Any change of getting a 7.1 RC1 RPM? I'm using the beta4 RPMs at the moment
> but don't seem to be any more recent ones.

I'm building a quickie RC1-1 RPM right now.  There are some other things
I need to do on the RPMset before final release -- and I plan on working
a while this Saturday on that -- but my week is so loaded that I'm going
to put out a rebuild of 7.1beta6->7.1RC1 as is -- once I get it to
build.....

Stay tuned...
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen wrote:
> 
> Mike Cannon-Brookes wrote:
> >
> > Any change of getting a 7.1 RC1 RPM? I'm using the beta4 RPMs at the moment
> > but don't seem to be any more recent ones.
> 
> I'm building a quickie RC1-1 RPM right now.  There are some other things
> I need to do on the RPMset before final release -- and I plan on working
> a while this Saturday on that -- but my week is so loaded that I'm going
> to put out a rebuild of 7.1beta6->7.1RC1 as is -- once I get it to
> build.....
> 
> Stay tuned...

Ok, 7.1RC1 RPM uploaded to ftp://ftp.postgresql.org/pub/dev/test-rpms as
before.

BIG NOTE:  These are built on Red Hat _7.0_ NOT 6.2 as previous ones
have been. The ODBC client build on 6.2 has been broken -- it built at
beta4, but now gives this error set at beta6/RC1:

ar crs libpsqlodbc.a info.o bind.o columninfo.o connection.o convert.o
drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
tuple.o tuplelist.o dlg_specific.o
ranlib libpsqlodbc.a
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -m486
-fno-strength-reduce -fpic -shared -Wl,-soname,libpsqlodbc.so.0
-Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o
drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
tuple.o tuplelist.o dlg_specific.o  -lm -Wl,-rpath,/usr/lib -o
libpsqlodbc.so.0.26
connection.o: In function `CC_connect':
connection.o(.text+0x914): undefined reference to
`check_client_encoding'
connection.o(.text+0x91a): undefined reference to
`check_client_encoding'
convert.o: In function `copy_statement_with_parameters':
convert.o(.text+0x110f): undefined reference to `multibyte_init'
convert.o(.text+0x1191): undefined reference to `multibyte_char_check'
convert.o(.text+0x11c3): undefined reference to `multibyte_strchr'
convert.o: In function `convert_special_chars':
convert.o(.text+0x2949): undefined reference to `multibyte_init'
convert.o(.text+0x29c4): undefined reference to `multibyte_char_check'
parse.o: In function `getNextToken':
parse.o(.text+0x151): undefined reference to `multibyte_char_check'
dlg_specific.o: In function `getDSNinfo':
dlg_specific.o(.text+0xd8c): undefined reference to
`check_client_encoding'
dlg_specific.o(.text+0xd98): undefined reference to
`check_client_encoding'
collect2: ld returned 1 exit status
make[3]: *** [libpsqlodbc.so.0.26] Error 1
make[3]: Leaving directory
`/root/rpm-building/redhat/BUILD/postgresql-7.1RC1/src/interfaces/odbc'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/root/rpm-building/redhat/BUILD/postgresql-7.1RC1/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/root/rpm-building/redhat/BUILD/postgresql-7.1RC1/src'
make: *** [all] Error 2


There are no other errors in the ODBC build that I could find.  Again --
this builds on Red Hat 7, but not RH 6.2.

Now, according to the cvsweb on postgresql.org, Bruce has just as of 14
hours ago done an update in this dir.  What updates were done between
beta4 and beta6? (Is that not when the flap about patches occurred?). 
Well, Red Hat 7 will build it -- and Red Hat 6.2 will now NOT build it
-- but it did build beta4 successfully.

Well, in any case, preliminary 7.1RC1 RPMS are up.  There are some odd
issues with the packaging that I am working on.  Be sure to read
README.rpm-dist -- attached to this message for your convenience.

THIS IS A PRERELEASE RPM. Please use for testing ONLY.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:
> BIG NOTE:  These are built on Red Hat _7.0_ NOT 6.2 as previous ones
> have been. The ODBC client build on 6.2 has been broken -- it built at
> beta4, but now gives this error set at beta6/RC1:

> ar crs libpsqlodbc.a info.o bind.o columninfo.o connection.o convert.o
> drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
> psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
> tuple.o tuplelist.o dlg_specific.o
> ranlib libpsqlodbc.a
> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -m486
> -fno-strength-reduce -fpic -shared -Wl,-soname,libpsqlodbc.so.0
> -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o
> drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
> psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
> tuple.o tuplelist.o dlg_specific.o  -lm -Wl,-rpath,/usr/lib -o
> libpsqlodbc.so.0.26
> connection.o: In function `CC_connect':
> connection.o(.text+0x914): undefined reference to
> `check_client_encoding'
> connection.o(.text+0x91a): undefined reference to
> `check_client_encoding'

It would appear you have a conflict about whether MULTIBYTE is defined
or not --- the code thinks so, but the makefile does not, since
multibyte.o is not seen in the link command.

The identical technique is used in libpq's makefile, so I'm not sure
why you do not see a link failure in libpq as well.
        regards, tom lane

Lamar Owen wrote:
> Well, in any case, preliminary 7.1RC1 RPMS are up.  There are some odd
> issues with the packaging that I am working on.  Be sure to read
> README.rpm-dist -- attached to this message for your convenience.

Forgot to attach the file. :-(.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11README.rpm
-----------------------------------------------------------------------------
Version 3.0, for PostgreSQL 7.1 RC1
Lamar Owen <lamar.owen@wgcr.org>

Updated by teg@redhat.com for 7.0.2 and to use FHS compliant doc paths
Updated to 7.0.3 and to reflect more of a cross-distribution slant.
Updated to 7.1RC1
-----------------------------------------------------------------------------

Contents:
0.)    Precautionary Statement for RPM packaging
1.)    Introduction, QuickStart, and credits
2.)    PostgreSQL RPM packages and rationale
3.)    Upgrading from an older version of PostgreSQL without losing data.
4.)    Regression Testing
5.)    Starting postmaster automatically on startup
6.)    Further Information Resource

PRECAUTIONS FOR RELEASE CANDIDATE RPMS.
-----------------------------------------------------------------------------
This RPM package of 7.1RC1 is being made available for testing purposes only.
This packaging is likely to change -- in particular, there will be at least
one more package (the contrib tree) added to the set before final release.

INTRODUCTION
-----------------------------------------------------------------------------
This document exists to explain the layout of the RPM's for PostgreSQL, to
explain how to migrate from an older version, and to explain WHY it can be
so difficult to upgrade PostgreSQL.

This document is written to be applicable to version 7.1 RC1 of
PostgreSQL, which is the current version of the RPM's as of this
writing.  These are Release Candidate RPM's -- things can and will change
before final release.

QUICKSTART
-----------------------------------------------------------------------------
If this is an upgrade, please go to section 3, UPGRADING.
If this is a fresh installation, simply start the postmaster using:
 /etc/rc.d/init.d/postgresql start  (on RedHat and TurboLinux)

On SuSE, please see the file 'README.linux' in this directory.

CREDITS
-----------------------------------------------------------------------------
Thomas Lockhart
Uncle George
Ryan Kirkpatrick
Trond Eivind Glomsrød
Mark Knox
Mike Mascari
Nicolas Huillard
Karl DeBisschop
Roger Luethi
Jeff Johnson


POSTGRESQL RPM PACKAGES AND RATIONALE.
-----------------------------------------------------------------------------
On RedHat Linux, prior to version 6.5, PostgreSQL was packaged in RPM form in
three (or four) packages:

postgresql:        The server and documentation
postgresql-clients:    The client libraries, the cli, and the tcl interface
postgresql-devel:    Development libraries (for the client-side)
postgresql-data:    A sample database -- not shipped with the 6.4 RPMS.

However, it was decided that a different split would be more appropriate for
users.  The 7.0 splitup allows more flexibility in installation, as well as
making the new clients into their own packages.  The new packages are:

postgresql:        Some clients and libraries, and documentation
postgresql-server:    Server executables and data files
postgresql-devel:    Client-side development libraries
postgresql-tcl:        TCL/TK client libraries and the pgaccess client
postgresql-perl:    PERL client module
postgresql-python:    The PygreSQL client library
postgresql-odbc:    Linux ODBC client (not required to use ODBC from Win95)
postgresql-jdbc:    JAR of the JDBC client
postgresql-test:    The regression tests and associated files.

For version 7.0.x, another package is being shipped, and one package has been
trimmed:
postgresql-tk:        Tk client and pgaccess.
postgresql-tcl:        Tcl client and PL ONLY.

For version 7.1, one more package is being shipped:
postgresql-libs:    client shared libraries.

For SuSE Linux <= 7.0, the packages are named differently, but with the same
functionality.  Here is a mapping:
SuSE:            RedHat:
-----            -----------------
postgres        postgresql
pg_serv            postgresql-server
pg_devel        postgresql-devel
pg_tcl            postgresql-tcl
pg_perl            postgresql-perl
pg_pyth            postgresql-python
pg_odbc            postgresql-odbc
pg_jdbc            postgresql-jdbc
pg_test            postgresql-test

There are other changes to the SuSE packages to make them conform to the
SuSE packaging standards.  SuSE Linux has been shipping their own packages.

While the repackaging will initially cause some confusion, it makes it
possible  to set up a RedHat linux machine to be only a client -- the server
is no longer required.  The clients were split out -- after all, a person who
needs the perl client may very well not need the tcl client, etc.  And, the
regression tests were added to give some confidence of the suitability of
PostgreSQL, as well as the stability of the server machine.  Additionally,
the regression tests can be used to help find hardware errors.

RPM FILE LOCATIONS.
-----------------------------------------------------------------------------
In compliance with the Linux FHS, the PostgreSQL RPM's install files in a manner
not consistent with most of the PostgreSQL documentation.  According to the
standard PostgreSQL documentation, PostgreSQL is installed under the directory
/usr/local/pgsql, with executables, source, and data existing in various
subdirectories.

Different distributions have different ideas of some of these file locations.
In particular, the documentation directory can be /usr/doc, /usr/doc/packages,
/usr/share/doc, /usr/share/doc/packages, or some other similar path.  The
RedHat 7 locations are listed below. On SuSE, substitute 'postgres' for
'postgresql' below, and 'pg_tk' for 'postgresql-tk' below.

However, the RPM's install the files like this:
Executables:        /usr/bin
Libaries:        /usr/lib
Documentation:        /usr/share/doc/postgresql-x.y.z
Contrib:        /usr/share/doc/postgresql-x.y.z/contrib
Source:            not installed
Data:            /var/lib/pgsql/data
Backup area:        /var/lib/pgsql/backup
Templates:        /usr/share/pgsql
Procedural Languages:    /usr/lib/pgsql
TK client docs:        /usr/share/doc/postgresql-tk-x.y.z
Development Headers:    /usr/include/pgsql
Other shared data:    /usr/share/pgsql

While it may seem gratuitous to place these files in different locations, the
FHS requires it -- distributions should not ever touch /usr/local.  It may
also seem like more work to keep track of where everything is -- but, that's
the beauty of RPM -- you don't have to keep track of the files, RPM does it
for you.

UPGRADING.
-----------------------------------------------------------------------------
NOTE: moving your existing data from /var/lib/pgsql to /var/lib/pgsql/data is
not currently automatic -- you will need to do this yourself at this release!
This change occurred between 6.5.3 and 7.0, so upgrading from priot to 7.0 to
7.0 or later might be difficult.  The rh-dump script is provided to ease this,
see below.

The single biggest problem with upgrading PostgreSQL RPM's has been the lack
of a reasonably automated upgrade process.  PostgreSQL has the property of
the binary on-disk database format changing between major versions (like
between 6.3 and 6.4).  However, a change from 6.5 to 6.5.3 does not change
the on-disk format.

This property (feature, misfeature, bug, whatever) has been a known property of
PostgreSQL since before it was called PostgreSQL -- it has always been this
way.  However, the means by which an upgrade is performed is not readily
performed in a fully automated fashion, as a "dump-initdb-restore" cycle has
to be performed. This doesn't appear to be too difficult -- however, dumping
the old database requires the old executables -- and, if you've already done
an rpm -U postgresql* (or upgraded from an older version of RedHat and didn't
specifically exclude the postgresql rpms), you no longer have the older
executables to dump your data. And your data is useless (until you reinstall
the old version, that is). All RPM's prior to late releases of version 6.5.
1 have this upgrade issue.

The newest RPM's for PostgreSQL attempt to make your job in upgrading a little
easier.  First, during the installation of the new RPM's, a copy is made of
all the executable files and libraries necessary to make a backup of your data.
Second, the initialization script in the new postgresql-server package detects
the version of any database found -- if the version is old, then the startup
of the new version is aborted.  However, if no database is found, a new one
is made.

One thing must be remembered -- due to the restructuring of the PostgreSQL
RPM's, you will have to manually select the postgresql-server package if you
want the server -- it is not installed by default in an upgrade. You can either
select it during the upgrade/install, or you can mount your RedHat CD and
install manually with rpm -i.

To facilitate upgrading, the postgresql-dump utility has been provided.  Look
at the man page for postgresql-dump to see its usage.  All executables to
restore the immediately prior version of the PostgreSQL database are placed in
the directory /usr/lib/pgsql/backup, and are accessed by the postgresql-dump
script.  The directory /usr/lib/pgsql/backup is owned by the postgres user --
you can use this directory to hold dump files and preserve directories.

The basic sequence is:
(as user postgres):
postgresql-dump -t /var/lib/pgsql/backup/db.bak -p /var/lib/pgsql/backup/old -d
(you can abort the ASCII dump with 'Q', as it uses more) Then, (as user root):

***** NOTE ***** ***** NOTE *****

The above script is broken. Use "rh-pgdump.sh targetfile" instead, remove the
old databases (/var/lib/pgsql/base) (or safer - move them somewhere else first),
start the database and follow the insert procedure described below.

***** NOTE ***** ***** NOTE *****

service postgresql start

(which will automatically create a new database structure) And finally,

(as user postgres):
psql -e template1 </var/lib/pgsql/backup/db.bak

Once you are satisfied that the data has been restored properly, you may remove
the dump file (/var/lib/pgsql/backup/db.bak) and the preserve directory
(/var/lib/pgsql/backup/old).

EXPLANATION OF STEPS:
-------------------------------------------------------------------------------
postgresql-dump: dumps the old database structure out, using the postmaster and
the backend saved during the rpm upgrade. This step MUST be done as user
postgres.

/etc/rc.d/init.d/postgresql start: initializes the new database structure that
the data from your old version will be restored into, does some sanity
checking, and starts the postmaster.  Due to the nature of some of the tasks,
this step must be done as root.

psql -e: restores the old database into the new structure created by the
previous step.

NOTE:
-------------------------------------------------------------------------------
If you have added tables, indices, or basically anything to the template1
database which is the default administrative database this script will NOT
upgrade your database. As a matter of fact you will lose your data included
in the template1 database. Please look at www.postgresql.org for information
on upgrading the template1 database. This is a known bug in the PostgreSQL
pg_dump and pg_dumpall utilities.

REGRESSION TESTING
-------------------------------------------------------------------------------
One of the features of the newer RPM sets is the capability to perform the
regression tests.  These tests stress your database installation and produce
results that give you assurances that the installation is complete, and that
your database machine is up to the task.

To run the regression tests under the RPM installation, make sure that
postmaster has been started (if not, su to root and execute the
'/etc/rc.d/init.d/postgresql start' init script), cd to
/usr/share/pgsql/test/regress, su to postgres, and execute the command line:
time ./pg_regress.sh --schedule=parallel_schedule
This command line will start the regression tests and will both show the
results to the screen and store the results in the file regress.out.
It will also give you a crude benchmark of how fast your machine performs.

If tests fail, please see the file regression.diffs in that directory.  If
you need help interpreting that file, contact the pgsql-ports list on
postgresql.org.

There are some tests that will almost always fail with RedHat Linux 5.x and 6.x
installations.  The geometry, float8, and on occassion the random test will
fail.  These failures are normal for RedHat 5.2 and 6.1.  For RedHat 6.1 with
certain i18n settings, there will be other tests fail.

New for 7.1RC1, all 76 tests should pass on RedHat 6.2 and RedHat 7.0.

For interpretation of the regression tests, see the PostgreSQL documentation.

STARTING POSTMASTER AUTOMATICALLY AT SYSTEM STARTUP
-------------------------------------------------------------------------------
RedHat Linux uses the System V Init package.  A startup script for PostgreSQL
is provided in the server package, as /etc/rc.d/init.d/postgresql.  To start
the postmaster, with sanity checking, as root, run
/etc/rc.d/init.d/postgresql start
to shut postmaster down,
/etc/rc.d/init.d/postgresql stop
There are other parameters to this script -- /etc/rc.d/init.d/postgresql for a
listing.

To get this script to run at system startup or any time the system switches into
runlevels 4, 5, or 6, run 'chkconfig --add postgresql', and the proper symlinks
will be created.  Check the chkconfig man page for more information.

This same script also works for TurboLinux, and any other distribution similar
enough to RedHat.  SuSE Linux uses a different approach, using a different
location and a different script, found at either /sbin/init.d/postgres or
/usr/sbin/rcpostgres.  Please see the SuSE 'README.linux' for more information.

MORE INFORMATION
-------------------------------------------------------------------------------
You can get more information at http://www.postgresql.org

Please help make this packaging better -- let me know if you find problems, or
better ways of doing things.  You can reach me by e-mail at
lamar@postgresql.org or pgsql-ports@postgresql.org.

SuSE information is available at feedback@suse.de
-----------------------------------------------------------------------------

Tom Lane wrote:
> It would appear you have a conflict about whether MULTIBYTE is defined
> or not --- the code thinks so, but the makefile does not, since
> multibyte.o is not seen in the link command.
> The identical technique is used in libpq's makefile, so I'm not sure
> why you do not see a link failure in libpq as well.

Hmmmm.  Hiroshi committed an update to GNUmakefile to 'enable multibyte
support' for ODBC.  But that was only 33 hours ago -- meaning it wasn't
updated in time for RC1. Lessee..... I'm rebuilding RC1 with Hiroshi's
GNUmakefile change as part of the RPMset patch -- and it succeeds.

But it succeeds on RH7 _without_ Hiroshi's patch.  Odd.  Lessee....
Examining my logs of the build on RH7 shows that the same error occurs
-- it just doesn't abort the build.  Argh.

This means that the binary up on the ftp site right now for ODBC is
broken. I'll fix it tonight or tomorrow -- and the source RPM won't
rebuild on RH 6.2.  I'll upload a -2 set tonight or tomorrow to fix
that, and a few other issues I found while dinking with it today.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

FYI: I successfully built a beta4 RPM for Mandrake, having to make only
the following changes:

1) add -fno-fast-math to the CFLAGS set from RPM_OPT_FLAGS. This fixes
the date/time rounding problems. Would seem to be a non-invasive fix to
put this in for every build, or to flag it as a Mandrake-only feature
(but I have not gotten a suggestion on how to do that).

2) explicitly remove Pg.bs from the list of files for the perl
installation. On my system (with perl-5.6.0) that is a zero-length file
which seems to disappear (or never gets copied) during the installation
process. Not sure why it does not propagate, but it does not seem to be
essential.

Comments?
                      - Thomas

Thomas Lockhart wrote:
> FYI: I successfully built a beta4 RPM for Mandrake, having to make only
> the following changes:

> 1) add -fno-fast-math to the CFLAGS set from RPM_OPT_FLAGS. This fixes
> the date/time rounding problems. Would seem to be a non-invasive fix to
> put this in for every build, or to flag it as a Mandrake-only feature
> (but I have not gotten a suggestion on how to do that).

I've got the code Tom and I came up with to deal with the LinuxPPC
nonsense of a few releases ago...  That or similar would be the ticket. 
A sed pipeline re-setting CFLAGS by removing 'unsafe' options from the
flags would be useful.

I'm working on a 'what distribution is this' deal for the spec file.
> 2) explicitly remove Pg.bs from the list of files for the perl
> installation. On my system (with perl-5.6.0) that is a zero-length file
> which seems to disappear (or never gets copied) during the installation
> process. Not sure why it does not propagate, but it does not seem to be
> essential.

Interesting. I have found a couple of other non-props -- including the
README.rpm-dist, for some reason.  I'm going to have to trace the build
in detail.  And the html docs tree is going to the wrong place... 

In any case, a unified or context diff against the 7.1beta4 spec would
be useful.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen wrote:
> 
> Tom Lane wrote:
> > It would appear you have a conflict about whether MULTIBYTE is defined
> > or not --- the code thinks so, but the makefile does not, since
> > multibyte.o is not seen in the link command.
> 
> > The identical technique is used in libpq's makefile, so I'm not sure
> > why you do not see a link failure in libpq as well.
> 
> Hmmmm.  Hiroshi committed an update to GNUmakefile to 'enable multibyte
> support' for ODBC.  But that was only 33 hours ago -- meaning it wasn't
> updated in time for RC1. Lessee..... I'm rebuilding RC1 with Hiroshi's
> GNUmakefile change as part of the RPMset patch -- and it succeeds.
> 

Oops I apologize for my mistake. I must have changed the
GNUmakefile when I committed multibyte support for ODBC.

regards,
Hiroshi Inoue

> In any case, a unified or context diff against the 7.1beta4 spec would
> be useful.

OK, here is a context diff of the spec file (note only two lines
changed). This addresses the "-fno-fast-math" problem on Mandrake (at
least 7.2 and earlier), and the "disappearing Pg.bs file" problem on
same.

                      - Thomas*** postgresql.spec    Mon Jan 29 07:14:13 2001
--- postgresql.spec.mdk    Fri Mar 23 04:10:42 2001
***************
*** 220,226 ****
  #    cp /usr/share/libtool/config.* .
  #fi

! CFLAGS="$RPM_OPT_FLAGS"

  ./configure --enable-hba --enable-locale  --with-CXX --prefix=/usr\
  %if %perl
--- 220,226 ----
  #    cp /usr/share/libtool/config.* .
  #fi

! CFLAGS="$RPM_OPT_FLAGS -fno-fast-math"

  ./configure --enable-hba --enable-locale  --with-CXX --prefix=/usr\
  %if %perl
***************
*** 280,285 ****
--- 280,286 ----
      # Get rid of the packing list generated by the perl Makefile, and build my own...
      find $RPM_BUILD_ROOT/usr/lib/perl5 -name .packlist -exec rm -f {} \;
      find $RPM_BUILD_ROOT/usr/lib/perl5 -type f -print | \
+         grep -v Pg.bs | \
          sed -e "s|$RPM_BUILD_ROOT/|/|g"  | \
          sed -e "s|.*/man/.*|&\*|" > perlfiles.list
      find $RPM_BUILD_ROOT/usr/lib/perl5 -type d -name Pg -print | \

Hiroshi Inoue wrote:
> Lamar Owen wrote:
> > Hmmmm.  Hiroshi committed an update to GNUmakefile to 'enable multibyte
> > support' for ODBC.  But that was only 33 hours ago -- meaning it wasn't
> > updated in time for RC1. Lessee..... I'm rebuilding RC1 with Hiroshi's
> > GNUmakefile change as part of the RPMset patch -- and it succeeds.
> Oops I apologize for my mistake. I must have changed the
> GNUmakefile when I committed multibyte support for ODBC.

I'm afraid I may have been misunderstood.  The change you made _fixed_
the problem -- it didn't cause it.  You made no error.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11