Обсуждение: PostgreSQL v6.4 BETA2 ...
I just built and regression tested the current source tree on both Solaris
x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
smooth...
Any arguments against getting a BETA2 out tomorrow afternoon?
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
> Any arguments against getting a BETA2 out tomorrow afternoon?
None, though I've just stumbled across some config stuff which would be
nice to clean up.
It came up when I tried upgrading compilers. The new one omitted an
explicit cpp, the preprocessor. Builds failed because references to it
are hardcoded, along with paths to find it, in at least two script files
for the backend.
It also turns out that autoconf already checks for cpp, or the
equivalent, but the result wasn't being used. So, fine, but...
autoconf concludes that "gcc -E" is equivalent to cpp on my system. And
it is, except that it needs an explicit bare "-" argument to try reading
from a pipe, which is how cpp was being used. I can test for "gcc" being
in the command, and add the argument, _or_ can change the scripts to
write a temporary file instead (they already write some temp files).
Comments? Suggestions??
- Tom
Oh, I'm probably going to revert back to the compiler package which
includes cpp...
I will be posting a configure.in tonight with further clean ups to the TCL/TK
configuration. TCL/TK compile information will now be obtained from the
tclConfig.sh and tkConfig.sh, without having to have a list of different
versions of TCL and TK to search for.
Two item I would like to bring up for discussion is:
1. Currently TCL/TK support is disabled if TCL is present, but TK is not. This
is not a good thing because the PL/tcl language is only dependant on TCL,
not TK. Also pgtclsh only requires TCL. I propose changing configure so
that TCL and TK support are seperate and the TCL dependant parts of the
postgreSQL distribution will still build even if TK is not present.
2. There is currently duplicate Makefile.tcldefs. I propose create a
Makefile.tcldefs and Makefile.tkdefs at the same directory level as
Makefile.global and have any Makefile that needs them include them from
that location. This would then become the 'standard' for compiling TCL
and TK based packages in the postgreSQL distribution.
Any comments and/or concerns?
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
> I will be posting a configure.in tonight with further clean ups to the TCL/TK > configuration. TCL/TK compile information will now be obtained from the > tclConfig.sh and tkConfig.sh, without having to have a list of different > versions of TCL and TK to search for. > > Two item I would like to bring up for discussion is: > > 1. Currently TCL/TK support is disabled if TCL is present, but TK is not. This > is not a good thing because the PL/tcl language is only dependant on TCL, > not TK. Also pgtclsh only requires TCL. I propose changing configure so > that TCL and TK support are seperate and the TCL dependant parts of the > postgreSQL distribution will still build even if TK is not present. > > 2. There is currently duplicate Makefile.tcldefs. I propose create a > Makefile.tcldefs and Makefile.tkdefs at the same directory level as > Makefile.global and have any Makefile that needs them include them from > that location. This would then become the 'standard' for compiling TCL > and TK based packages in the postgreSQL distribution. > > Any comments and/or concerns? Be aware I removed the TCL_LIB, ... stuff from configure.in this morning. That was the old stuff, and your new stuff made it unnecessary. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> autoconf concludes that "gcc -E" is equivalent to cpp on my system. And > it is, except that it needs an explicit bare "-" argument to try reading > from a pipe, which is how cpp was being used. I can test for "gcc" being > in the command, and add the argument, _or_ can change the scripts to > write a temporary file instead (they already write some temp files). Add the following to configure.in after AC_PROG_CPP and use the resultant flag from CPPSTDIN: (either nothing or -) --- cut here --- AC_DEFUN(AC_TRY_CPPSTDIN, [AC_REQUIRE_CPP()dnl cat > conftest.$ac_ext <<EOF [#]line __oline__ "configure" #include "confdefs.h" [$1] EOF ac_try="$ac_cpp $CPPSTDIN <conftest.$ac_ext >/dev/null 2>conftest.out" AC_TRY_EVAL(ac_try) ac_err=`grep -v '^ *+' conftest.out` if test -z "$ac_err"; then ifelse([$2], , :, [rm -rf conftest* $2]) else echo "$ac_err" >&AC_FD_CC echo "configure: failed program was:" >&AC_FD_CC cat conftest.$ac_ext >&AC_FD_CC ifelse([$3], , , [ rm -rf conftest* $3 ])dnl fi rm -f conftest*]) AC_MSG_CHECKING(how to use cpp with stdin) if test -z "$CPPSTDIN"; then AC_CACHE_VAL(ac_cv_cpp_stdin, [ CPPSTDIN="" AC_TRY_CPPSTDIN([#include <assert.h> Syntax Error], , CPPSTDIN="-") ac_cv_cpp_stdin="$CPPSTDIN"]) CPPSTDIN="$ac_cv_cpp_stdin" else ac_cv_cpp_stdin="$CPPSTDIN" fi AC_MSG_RESULT($CPP $CPPSTDIN) AC_SUBST(CPPSTDIN) --- cut here --- Taral P.S. Yes, do use the DEFUN just in case we want to add more broken variants later :)
On Tue, 13 Oct 1998, Billy G. Allie wrote:
> I will be posting a configure.in tonight with further clean ups to the TCL/TK
> configuration. TCL/TK compile information will now be obtained from the
> tclConfig.sh and tkConfig.sh, without having to have a list of different
> versions of TCL and TK to search for.
>
> Two item I would like to bring up for discussion is:
>
> 1. Currently TCL/TK support is disabled if TCL is present, but TK is not. This
> is not a good thing because the PL/tcl language is only dependant on TCL,
> not TK. Also pgtclsh only requires TCL. I propose changing configure so
> that TCL and TK support are seperate and the TCL dependant parts of the
> postgreSQL distribution will still build even if TK is not present.
>
> 2. There is currently duplicate Makefile.tcldefs. I propose create a
> Makefile.tcldefs and Makefile.tkdefs at the same directory level as
> Makefile.global and have any Makefile that needs them include them from
> that location. This would then become the 'standard' for compiling TCL
> and TK based packages in the postgreSQL distribution.
>
> Any comments and/or concerns?
> --
These changes sound great for post-v6.4...
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
>
>
> I just built and regression tested the current source tree on both Solaris
> x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> smooth...
>
> Any arguments against getting a BETA2 out tomorrow afternoon?
Have a crashing backend after a huge transaction on the next
insert into a table with indices. Crash is reproducable and
seems to be due to a corrupted index file.
Recompiling with COPT=-g now...
>
> Marc G. Fournier scrappy@hub.org
> Systems Administrator @ hub.org
> scrappy@{postgresql|isc}.org ICQ#7615664
>
>
>
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
That was me:
>
> >
> >
> > I just built and regression tested the current source tree on both Solaris
> > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > smooth...
> >
> > Any arguments against getting a BETA2 out tomorrow afternoon?
>
> Have a crashing backend after a huge transaction on the next
> insert into a table with indices. Crash is reproducable and
> seems to be due to a corrupted index file.
>
> Recompiling with COPT=-g now...
>
Harrr - using text_ops on an int4 field in CREATE INDEX
doesn't make much sense.
Bruce, please add 6.5 TODO:
Parser must check on CREATE INDEX that the opcdeftype of the
used operator class is compatible with the indexed field or
the index functions return type.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
I will be posting a configure.in tonight with further clean ups to the TCL/TK configuration. TCL/TK compile information will now be obtained from the tclConfig.sh and tkConfig.sh, without having to have a list of different versions of TCL and TK to search for. These ideas sound great, but I don't understand one thing. How do you locate the *Config.sh scripts without looking in a bunch of directories until you find them? Unless there is a general means of finding these which 1) doesn't involve checking directories associated with different versions of tcl/tk, and 2) does allow for the possibility that tcl/tk may not be installed in a particular filesystem (/usr/local, for example), I strongly recommend keeping the part of configure that searches for the location of tcl/tk. Perhaps we don't need to store the location of include/library files based on the configure script, but I think we do need to use essentially the same mechanism to find the *Config.sh scripts. Cheers, Brook
> [...] TCL/TK compile information will now be obtained from the
> tclConfig.sh and tkConfig.sh, without having to have a list of different
> versions of TCL and TK to search for.
>
> These ideas sound great, but I don't understand one thing.
>
> How do you locate the *Config.sh scripts without looking in a bunch of
> directories until you find them?
>
> Unless there is a general means of finding these which 1) doesn't
> involve checking directories associated with different versions of
> tcl/tk, and 2) does allow for the possibility that tcl/tk may not be
> installed in a particular filesystem (/usr/local, for example), I
> strongly recommend keeping the part of configure that searches for the
> location of tcl/tk. Perhaps we don't need to store the location of
> include/library files based on the configure script, but I think we do
> need to use essentially the same mechanism to find the *Config.sh
> scripts.
I wasn't clear enough in my explaination. I still search directories for the
*Config.sh files, but I generalized it so that a list of TCL and TK versions do not have to be maintained. Here is the
segmentof code that performs the search for tclConfig.sh:
library_dirs="$LIBRARY_DIRS /usr/lib"
TCL_CONFIG_SH=
for dir in $library_dirs; do
if test -d "$dir" -a -r "$dir/tclConfig.sh"; then
TCL_CONFIG_SH=$dir/tclConfig.sh
break
fi
for tcl_dir in $dir/tcl[0-9]*.[0-9]*
do
if test -d "$tcl_dir" -a -r "$tcl_dir/tclConfig.sh"
then
TCL_CONFIG_SH=$tcl_dir/tclConfig.sh
break 2
fi
done
done
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
I wasn't clear enough in my explaination. I still search
directories for the *Config.sh files, but I generalized it so that
a list of TCL and TK versions do not have to be maintained.
OK. That clears things up, now. But ...
Here is the segment of code that performs the search for
tclConfig.sh:
for tcl_dir in $dir/tcl[0-9]*.[0-9]*
do
...
done
I think that this will fail by finding the LOWER version of tcl
before a higher version. For example, if I have both 7.6 and 8.0
installed, won't this find 7.6 first?
Might there not be installations with an old version lying around?
Should the script be enhanced to at least report on ALL versions
found?
Should the script simply assign for each version found, rather than
breaking out of the loop? That might have a better chance at catching
the highest version; although, it doesn't won't order 8.9 and 8.10
correctly.
Cheers,
Brook
> > Harrr - using text_ops on an int4 field in CREATE INDEX > doesn't make much sense. > > Bruce, please add 6.5 TODO: > > Parser must check on CREATE INDEX that the opcdeftype of the > used operator class is compatible with the indexed field or > the index functions return type. But, we don't require ops* anymore. Should we prevent people from using whatever ops they want? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> I think that this will fail by finding the LOWER version of tcl
> before a higher version. For example, if I have both 7.6 and 8.0
> installed, won't this find 7.6 first?
Sorry, I've lost track of the discussion. Is it the case that people
know that pgtcl does not install at the moment? On my machine the
installation procedure has trouble finding one of the shell files under
discussion...
- Tom
On Wed, 14 Oct 1998, Jan Wieck wrote:
> >
> >
> > I just built and regression tested the current source tree on both Solaris
> > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > smooth...
> >
> > Any arguments against getting a BETA2 out tomorrow afternoon?
>
> Have a crashing backend after a huge transaction on the next
> insert into a table with indices. Crash is reproducable and
> seems to be due to a corrupted index file.
>
> Recompiling with COPT=-g now...
I saw Bruce's last on this...will wait until you guys have this
sorted out before I build the snapshot...
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
>
> On Wed, 14 Oct 1998, Jan Wieck wrote:
>
> > >
> > >
> > > I just built and regression tested the current source tree on both Solaris
> > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
> > > smooth...
> > >
> > > Any arguments against getting a BETA2 out tomorrow afternoon?
> >
> > Have a crashing backend after a huge transaction on the next
> > insert into a table with indices. Crash is reproducable and
> > seems to be due to a corrupted index file.
> >
> > Recompiling with COPT=-g now...
>
> I saw Bruce's last on this...will wait until you guys have this
> sorted out before I build the snapshot...
>
Was my fault - not a bug.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> > I think that this will fail by finding the LOWER version of tcl > > before a higher version. For example, if I have both 7.6 and 8.0 > > installed, won't this find 7.6 first? > > Sorry, I've lost track of the discussion. Is it the case that people > know that pgtcl does not install at the moment? On my machine the > installation procedure has trouble finding one of the shell files under > discussion... > Can you provide more details, such as the error messages generated by make? -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
> On Wed, 14 Oct 1998, Jan Wieck wrote: > > > > > > > > > > I just built and regression tested the current source tree on both Solaris > > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was > > > smooth... > > > > > > Any arguments against getting a BETA2 out tomorrow afternoon? > > > > Have a crashing backend after a huge transaction on the next > > insert into a table with indices. Crash is reproducable and > > seems to be due to a corrupted index file. > > > > Recompiling with COPT=-g now... > > I saw Bruce's last on this...will wait until you guys have this > sorted out before I build the snapshot... Fixed. He had the wrote ops_ on the index. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > I think that this will fail by finding the LOWER version of tcl > > before a higher version. For example, if I have both 7.6 and 8.0 > > installed, won't this find 7.6 first? > > Sorry, I've lost track of the discussion. Is it the case that people > know that pgtcl does not install at the moment? On my machine the > installation procedure has trouble finding one of the shell files under > discussion... This is news to me. The current code looks for tclConfig.sh and tkConfig.sh in the various standard directories. In my case, they are in /usr/contrib/lib. Can you add the directory that has those file to your search path include dirs. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-----BEGIN PGP SIGNED MESSAGE-----
library_dirs="$LIBRARY_DIRS /usr/lib"
TCL_CONFIG_SH=
for dir in $library_dirs; do
[...]
done
If you can assume that Tcl is installed and the version the user wants
is first in their path, you should be able to limit this to
library_dirs=`echo 'puts $auto_path' | tclsh`
roland
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNiVfs+oW38lmvDvNAQFpPgP9Gsk515V66r0BHUk9hIE8atCyxu08QIpo
kRWGLd3gO5vs04Y56OrNAwCZuddfr1lx+S01MP6G5HKdHWQ9z1mDGixODYrdW9K2
39HT3OHJ9YEzgoQV77m1Ef9OPmLpuboXMg1iEd4+Wv/PJrTvVVmLHCD98wMjgpgF
BenOPn5wV0w=
=NiLZ
-----END PGP SIGNATURE-----
--
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 101 West 15th St #4NN
New York, NY 10011
> I think that this will fail by finding the LOWER version of tcl
> before a higher version. For example, if I have both 7.6 and 8.0
> installed, won't this find 7.6 first?
>
> Might there not be installations with an old version lying around?
>
> Should the script be enhanced to at least report on ALL versions
> found?
>
> Should the script simply assign for each version found, rather than
> breaking out of the loop? That might have a better chance at catching
> the highest version; although, it doesn't won't order 8.9 and 8.10
> correctly.
Actually, I've looked at the configure for TCL and concluded came to the
following conclusions:
1. By default, the *Config.sh files go in the same directory as the library
files (default: /usr/local/lib).
2. If you built more than 1 version of TCL/TK, the *Config.sh will reflect
the last version built unless you override the default location of the
libraries.
3. If you more than one version of TCL/TK and want to use a specific version,
you need to tell configure where the *Config.sh file you want to use are
with the --with-libs or --with-library option.
Bearing these points in mind, I will be removing the code that looks in tclX.Y
(where X.Y is the version) and tkX.Y directories. It will only look for
*Config.sh files in the following directories (in the order given):
$LIBRARY_DIRS (set with --with-libs or --with-libraries)
/usr/local/lib
/usr/contrib/lib
/opt/lib
/usr/lib
This method will make searching for various versions TCL/TK unnecessary while
still being able to find the correct TCL/TK in most cases.
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
> library_dirs="$LIBRARY_DIRS /usr/lib" > TCL_CONFIG_SH= > for dir in $library_dirs; do > [...] > done > > If you can assume that Tcl is installed and the version the user wants > is first in their path, you should be able to limit this to > > library_dirs=`echo 'puts $auto_path' | tclsh` > This is one of those cases where you sit back and think "Now why didn't I think of that!" The only thing I would add is to allow $LIBRARY_DIR to be searched first to allow an alternate version of TCL/TK to be specified. Also, I would add a check to see if tclsh is in the path. Can anyone think of a good reason not to use this method? -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
> Actually, I've looked at the configure for TCL and concluded came to the > following conclusions: > > 1. By default, the *Config.sh files go in the same directory as the library > files (default: /usr/local/lib). > > 2. If you built more than 1 version of TCL/TK, the *Config.sh will reflect > the last version built unless you override the default location of the > libraries. > > 3. If you more than one version of TCL/TK and want to use a specific version, > you need to tell configure where the *Config.sh file you want to use are > with the --with-libs or --with-library option. > > Bearing these points in mind, I will be removing the code that looks in tclX.Y > (where X.Y is the version) and tkX.Y directories. It will only look for > *Config.sh files in the following directories (in the order given): FYI, I may have already done that in configure.in. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > Sorry, I've lost track of the discussion. Is it the case that people
> > know that pgtcl does not install at the moment? On my machine the
> > installation procedure has trouble finding one of the shell files
> > under discussion...
> Can you provide more details, such as the error messages generated by
> make?
Sorry, false alarm. I had seen it fail recently, but it is working great
now.
- Tom