int 8 on FreeBSD
Hi all,
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.
Holm
PS:
sorry for my poor english.
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
NetBSD is the same way. Any chance of someone coming up with a patch
if int8 isn't supported?
--Michael
Holm Tiffe <holm@freibergnet.de> writes:
Show quoted text
Hi all,
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.Holm
PS:
sorry for my poor english.
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
Import Notes
Reply to msg id not found: HolmTiffesmessageofWed3Mar1999082816+0100
On Wed, 3 Mar 1999, Holm Tiffe wrote:
Hi all,
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.
Its only an odd assumption to those on FreeBSD...we tend to be the only
ones that pervert most of the "standards" as far as installation
directories are concerned, and require specific handholding to get things
to install :(
See /usr/ports/databases/postgresql/Makefile, where it provides the
various --with-tcl= directives required...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote:
On Wed, 3 Mar 1999, Holm Tiffe wrote:
Hi all,
[..]
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.Its only an odd assumption to those on FreeBSD...we tend to be the only
ones that pervert most of the "standards" as far as installation
directories are concerned, and require specific handholding to get things
to install :(
..but it is possible on FreeBSD to run several different tcl/tk pairs
in parallel, so it turns out that it is the better way and I can't
remeber that I have had such problems with an other package.
Personally I HATE GNU's autoconf, it is really a pain to get things
working on "non standard environments". I prefer a Makefile in which
I can set options directly. But this is my own opinion and I can
understand why others doesn't think so.
See /usr/ports/databases/postgresql/Makefile, where it provides the
various --with-tcl= directives required...
Yeah, I've build PGSQL without the ports, because there was no port
of 6.4.2 to the time I needed it, and I've got it finally working.
Another question:
Watfor is the patches directory on ftp.postgresql.org/pub ?
It contains almost nothing of the actual patches from
the -patches mailinglist.
This makes it really not simple to get a halfways actual setup
without sup/cvsup or so...
Holm
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
On Wed, 3 Mar 1999, Holm Tiffe wrote:
The Hermit Hacker wrote:
On Wed, 3 Mar 1999, Holm Tiffe wrote:
Hi all,
[..]
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.Its only an odd assumption to those on FreeBSD...we tend to be the only
ones that pervert most of the "standards" as far as installation
directories are concerned, and require specific handholding to get things
to install :(..but it is possible on FreeBSD to run several different tcl/tk pairs
in parallel, so it turns out that it is the better way and I can't
remeber that I have had such problems with an other package.
Agreed, but, as far as I've seen so far (and I use FreeBSD myself, and
hate it), FreeBSD is the only one that confuses the whole mess by doing
this :(
Personally I HATE GNU's autoconf, it is really a pain to get things
working on "non standard environments". I prefer a Makefile in which
I can set options directly. But this is my own opinion and I can
understand why others doesn't think so.
As far as tk/tcl is concerned, FreeBSD is the only "non-standard
environment" that I'm aware of...the rest all install to standard
locations...
Watfor is the patches directory on ftp.postgresql.org/pub ?
It contains almost nothing of the actual patches from
the -patches mailinglist.
This makes it really not simple to get a halfways actual setup
without sup/cvsup or so...
-patches mailing list is primarily -CURRENT tree stuff, untested. The
patches directory is pretty much tested stuff that we feel confident in
ppl using...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote:
On Wed, 3 Mar 1999, Holm Tiffe wrote:
The Hermit Hacker wrote:
On Wed, 3 Mar 1999, Holm Tiffe wrote:
Hi all,
[..]
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.Its only an odd assumption to those on FreeBSD...we tend to be the only
ones that pervert most of the "standards" as far as installation
directories are concerned, and require specific handholding to get things
to install :(..but it is possible on FreeBSD to run several different tcl/tk pairs
in parallel, so it turns out that it is the better way and I can't
remeber that I have had such problems with an other package.Agreed, but, as far as I've seen so far (and I use FreeBSD myself, and
hate it),
Why you use it ?
FreeBSD is the only one that confuses the whole mess by doing
this :(
I think, this is because FreeBSD has learned. There was a time who Tcl/Tk
versions where released nearly every day. FreeBSD has had an "imported"
tcl version in it's source dist. All Tcl versions where incomatible
to each other this time, and I've had to work around this several times.
The current behavior of FreeBSD is the only one solution for this.
Think of Linux, which libc today ?
Personally I HATE GNU's autoconf, it is really a pain to get things
working on "non standard environments". I prefer a Makefile in which
I can set options directly. But this is my own opinion and I can
understand why others doesn't think so.As far as tk/tcl is concerned, FreeBSD is the only "non-standard
environment" that I'm aware of...the rest all install to standard
locations...
No, that was not only relating to Tcl/Tk, there are many other things
like configuring a gcc-cross build environment and so on.
Watfor is the patches directory on ftp.postgresql.org/pub ?
It contains almost nothing of the actual patches from
the -patches mailinglist.
This makes it really not simple to get a halfways actual setup
without sup/cvsup or so...-patches mailing list is primarily -CURRENT tree stuff, untested. The
patches directory is pretty much tested stuff that we feel confident in
ppl using...
Hmm, there must be very few confident things, when I take a look to this
patch directory....
A "Migration Path" (deltas) from on release to the next is on my wishlist,
to get a customers installation up to date without the full net access.
Holm
Ps: sorry for my poor english
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
On Wed, 3 Mar 1999, Holm Tiffe wrote:
The Hermit Hacker wrote:
Agreed, but, as far as I've seen so far (and I use FreeBSD myself, and
hate it),Why you use it ?
I knew after I typed that that I had worded it wrong...I hate the way it
installs various ports, like tk/tcl ... I don't hate FreeBSD itself...
FreeBSD is the only one that confuses the whole mess by doing
this :(I think, this is because FreeBSD has learned. There was a time who Tcl/Tk
versions where released nearly every day. FreeBSD has had an "imported"
tcl version in it's source dist. All Tcl versions where incomatible
to each other this time, and I've had to work around this several times.
The current behavior of FreeBSD is the only one solution for this.
Think of Linux, which libc today ?
The "only one solution for this" is the standard/accepted one by everyone
*except* for FreeBSD, that is *why* we have standards...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int
format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...
I had originally coded in %qd for some platforms, but *strongly* recall
that those platforms which supported %qd also supported %lld, so we
removed the %qd variant.
If int8 really doesn't work on FreeBSD, shame on the FreeBSDers for not
bringing it up earlier. But, it can't be that simple. If it *really*
doesn't work on FreeBSD, could it be related to relatively recent
changes in compilers or libraries (or are you running an old version of
FreeBSD)?
scrappy, can you take a look at this on your platform?
- Tom
The Hermit Hacker wrote:
On Wed, 3 Mar 1999, Holm Tiffe wrote:
The Hermit Hacker wrote:
Agreed, but, as far as I've seen so far (and I use FreeBSD myself, and
hate it),Why you use it ?
I knew after I typed that that I had worded it wrong...I hate the way it
installs various ports, like tk/tcl ... I don't hate FreeBSD itself...FreeBSD is the only one that confuses the whole mess by doing
this :(I think, this is because FreeBSD has learned. There was a time who Tcl/Tk
versions where released nearly every day. FreeBSD has had an "imported"
tcl version in it's source dist. All Tcl versions where incomatible
to each other this time, and I've had to work around this several times.
The current behavior of FreeBSD is the only one solution for this.
Think of Linux, which libc today ?The "only one solution for this" is the standard/accepted one by everyone
*except* for FreeBSD, that is *why* we have standards...
I meant: the only one solution to install more than one such package on one
machine at a time.
(Why we have problems to express our self today ? :-))
[ok, I have languages related problems too...]
back to standards:
Why a PC uses metric AND inch screws ?
Why we have MS Windows (grr), MacOS, OS/2, *BSD, Linux .... ?
(order isn't important here)
It's because we all have different tastes ...
You hate it, an I simply accept it.
I have had to use tcl3 and tcl8 on a customers machine.
Holm
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
Thomas G. Lockhart wrote:
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int
format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...I had originally coded in %qd for some platforms, but *strongly* recall
that those platforms which supported %qd also supported %lld, so we
removed the %qd variant.If int8 really doesn't work on FreeBSD, shame on the FreeBSDers for not
bringing it up earlier.
:-)
But, it can't be that simple.
The regression test means it is, and this is possibly the reason why it
isn't fixed jet :-)
If it *really*
doesn't work on FreeBSD, could it be related to relatively recent
changes in compilers or libraries (or are you running an old version of
FreeBSD)?
No, this is my development box:
4.0-CURRENT FreeBSD 4.0-CURRENT #6: Mon Mar 1 12:55:03 CET 1999
It is a very current system, but I've stumbled over this some time
bevore (int8 was a contrib package this times)
Holm
--
FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development
Systemhaus f�r Daten- und Netzwerktechnik phone +49 3731 781279
Unternehmensgruppe Liebscher & Partner fax +49 3731 781377
D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.
I have to agree here. We have an localized version of Tcl/Tk package
for FreeBSD having TkConfig.sh under /usr/local/lib/tk4.2jp/. I always
hand-edit configure to let it recognize tkConfigure.sh.
---
Tatsuo Ishii
Import Notes
Reply to msg id not found: YourmessageofWed03Mar1999082816+0100.19990303082816.A12836@pegasus.freibergnet.de | Resolved by subject fallback
-----BEGIN PGP SIGNED MESSAGE-----
"Tatsuo" == Tatsuo Ishii <t-ishii@sra.co.jp> writes:
BTW: why the configure script think's that tcl and tk includes
(tclConfig.sh,tkConfig.sh) must reside in the same directory ?
That's really an odd assumtion.
Tatsuo> I have to agree here. We have an localized version of
Tatsuo> Tcl/Tk package for FreeBSD having TkConfig.sh under
Tatsuo> /usr/local/lib/tk4.2jp/. I always hand-edit configure to
Tatsuo> let it recognize tkConfigure.sh. --- Tatsuo Ishii
I don't understand the complaint; doesn't
--with-tclconfig=/usr/local/lib/tk4.2jp
work for you? or is you tkConfig.sh really called tkConfigure.sh
(maybe that is what is breaking it...).
roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 101 West 15th St #4NN
rbroberts@acm.org New York, NY 10011
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNt4AouoW38lmvDvNAQGvpgQAgiJBjhnCL62HlKJm3oVAz+ew6AABNMzv
i9HGhOOaDU072xgSt3ay/y7vr25TG5XBrhNvuo7zLkrr/RlHV4iSEXM3Nrzga9CV
/k4teT7IfJ6ZVHOLsEoMPhiEeKimD3tlzIuZSSvc3SDOZHOreaV15V43xYYWtV79
MFvFCjDJGUo=
=QDBy
-----END PGP SIGNATURE-----
Import Notes
Reply to msg id not found: TatsuoIshiismessageofThu04Mar1999105652+0900
Tatsuo> I have to agree here. We have an localized version of
Tatsuo> Tcl/Tk package for FreeBSD having TkConfig.sh under
Tatsuo> /usr/local/lib/tk4.2jp/. I always hand-edit configure to
Tatsuo> let it recognize tkConfigure.sh. --- Tatsuo IshiiI don't understand the complaint; doesn't
--with-tclconfig=/usr/local/lib/tk4.2jp
work for you? or is you tkConfig.sh really called tkConfigure.sh
(maybe that is what is breaking it...).
I don't think that works. Since tclConfig.sh is under
/usr/local/lib/tcl7.6jp/ in my configuration. As already pointed out,
the problem is configure doesn't allow tclConfig.sh and tkConfig.sh
lives in separate directory.
--
Tatsuo Ishii
Import Notes
Reply to msg id not found: Yourmessageof03Mar1999224020EST.m3hfs1zzvf.fsf@ptolemy.rlent.pnet | Resolved by subject fallback
On Thu, 4 Mar 1999, Tatsuo Ishii wrote:
Tatsuo> I have to agree here. We have an localized version of
Tatsuo> Tcl/Tk package for FreeBSD having TkConfig.sh under
Tatsuo> /usr/local/lib/tk4.2jp/. I always hand-edit configure to
Tatsuo> let it recognize tkConfigure.sh. --- Tatsuo IshiiI don't understand the complaint; doesn't
--with-tclconfig=/usr/local/lib/tk4.2jp
work for you? or is you tkConfig.sh really called tkConfigure.sh
(maybe that is what is breaking it...).I don't think that works. Since tclConfig.sh is under
/usr/local/lib/tcl7.6jp/ in my configuration. As already pointed out,
the problem is configure doesn't allow tclConfig.sh and tkConfig.sh
lives in separate directory.
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
That Works?!?! Damn. One thing I never thought to try.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
That Works?!?! Damn. One thing I never thought to try.
Actually, just tried it here, and if it works in our ports collection, it
doesn't work outside of it :(
Am going to play aroudn with it from home tonight...would like to get
that, at least, fixed for v6.4.3 also...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
That Works?!?! Damn. One thing I never thought to try.
Actually, just tried it here, and if it works in our ports collection, it
doesn't work outside of it :(Am going to play aroudn with it from home tonight...would like to get
that, at least, fixed for v6.4.3 also...
How 'bout adding a --with-tkconfig=DIR to configure with it defaulting
to tclconfig's DIR?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Sounds reasonable to me...want to do it up and submit a quick patch? I
won't get a chance til later tonight...
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
That Works?!?! Damn. One thing I never thought to try.
Actually, just tried it here, and if it works in our ports collection, it
doesn't work outside of it :(Am going to play aroudn with it from home tonight...would like to get
that, at least, fixed for v6.4.3 also...How 'bout adding a --with-tkconfig=DIR to configure with it defaulting
to tclconfig's DIR?Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On 04-Mar-99 The Hermit Hacker wrote:
Sounds reasonable to me...want to do it up and submit a quick patch? I
won't get a chance til later tonight...
Ok. Having never played with autoconf, I think I got it anyway. I do
have a minor problem, tho, as I've never gotten tk/tcl to compile cleanly
with PostgreSQL. It can never find tcl.h and tk.h unless I play with the
makefiles. Whatever the case, attached is a diff for configure.in I hope
we can get it tested by a few different platforms. Also would someone
take a look at the --help text for it? I guess it's ok but not exactly
the clearest. I'm also going to take another look at why the header
files for tk/tck are getting missed.
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
On Thu, 4 Mar 1999, Vince Vielhaber wrote:
On Thu, 4 Mar 1999, The Hermit Hacker wrote:
FreeeBSD does it as:
--with-tclconfig"/usr/local/lib/tk4.2jp /usr/local/lib/tcl7.6jp"
That Works?!?! Damn. One thing I never thought to try.
Actually, just tried it here, and if it works in our ports collection, it
doesn't work outside of it :(Am going to play aroudn with it from home tonight...would like to get
that, at least, fixed for v6.4.3 also...How 'bout adding a --with-tkconfig=DIR to configure with it defaulting
to tclconfig's DIR?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Attachments:
configure.in.difftext/plain; SizeOnDisk=942; charset=us-ascii; name=configure.in.diffDownload
--- configure.in.orig Thu Mar 4 14:58:14 1999
+++ configure.in Thu Mar 4 15:15:32 1999
@@ -287,6 +287,21 @@
]
)
+dnl We see if the path to the TK configuration scripts is specified.
+dnl This will overide the use of tclsh to find the paths to search.
+
+AC_ARG_WITH(tkconfig,
+ [ --with-tkconfig=DIR tkConfig.sh is in DIR],
+ [
+ case "$withval" in
+ "" | y | ye | yes | n | no)
+ AC_MSG_ERROR([*** You must supply an argument to the --with-tkconfig optio
n.])
+ ;;
+ esac
+ TK_DIRS="$withval"
+ ]
+)
+
dnl We exclude perl support unless we override it with --with-perl
AC_MSG_CHECKING(setting USE_PERL)
AC_ARG_WITH(
@@ -812,7 +827,7 @@
then
library_dirs=`echo 'puts $auto_path' | $TCLSH`
fi
- library_dirs="$TCL_DIRS $library_dirs"
+ library_dirs="$TCL_DIRS $TK_DIRS $library_dirs"
for dir in $library_dirs; do
if test -d "$dir" -a -r "$dir/tclConfig.sh"; then
TCL_CONFIG_SH=$dir/tclConfig.sh
On 04-Mar-99 Vince Vielhaber wrote:
On 04-Mar-99 The Hermit Hacker wrote:
Sounds reasonable to me...want to do it up and submit a quick patch? I
won't get a chance til later tonight...Ok. Having never played with autoconf, I think I got it anyway. I do
have a minor problem, tho, as I've never gotten tk/tcl to compile cleanly
with PostgreSQL. It can never find tcl.h and tk.h unless I play with the
makefiles. Whatever the case, attached is a diff for configure.in I hope
we can get it tested by a few different platforms. Also would someone
take a look at the --help text for it? I guess it's ok but not exactly
the clearest. I'm also going to take another look at why the header
files for tk/tck are getting missed.
An update here, the include dirs need to be added to --with-includes and I
had a small typo in that line. (stupid computers, they should know what I
mean no matter what I type!). It all compiled without incident :)
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Holm Tiffe wrote:
Hi all,
Hi, Holm,
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...
Here are the patches I've used to enable int8 support.
Since my patches modify configure.in, you'll need to install
autoconf and regenerate the configure script.
Hope this helps,
Kevin.
==============================================================
--- ./src/backend/port/snprintf.c 1998/12/25 02:20:41 64.2
+++ ./src/backend/port/snprintf.c 1999/01/19 00:37:40 64.2.1.1
@@ -49,7 +49,7 @@
#include <sys/param.h> /* IRIX doesn't do 'long long' in va_arg(), so use a typedef */
-#ifdef HAVE_LONG_LONG_INT_64
+#if defined(HAVE_LONG_INT_64) || defined(HAVE_LONG_LONG_INT) ||
defined(HAVE_QUAD_INT_64)
typedef long long long_long;
typedef unsigned long long ulong_long;
#endif
--- ./src/include/utils/int8.h 1998/09/11 17:16:11 64.2
+++ ./src/include/utils/int8.h 1999/01/19 00:37:41 64.2.1.1
@@ -35,11 +35,18 @@ #define INT64_FORMAT "%lld"
#else
+#ifdef HAVE_QUAD_INT_64
+/* We have working support for "long long", use that */
+typedef long long int64;
+
+#define INT64_FORMAT "%qd"
+#else
/* Won't actually work, but fall back to long int so that int8.c compiles
*/
typedef long int int64; #define INT64_FORMAT "%ld"
#define INT64_IS_BUSTED
+#endif
#endif
#endif
--- ./src/include/config.h.in 1998/12/13 20:08:24 64.2
+++ ./src/include/config.h.in 1999/01/19 00:37:41 64.2.1.1
@@ -267,6 +267,9 @@
/* Set to 1 if type "long long int" works and is 64 bits */
#undef HAVE_LONG_LONG_INT_64+/* Set to 1 if type "long long" works and is 64 bits */
+#undef HAVE_QUAD_INT_64
+
/* Define as the base type of the last arg to accept */
#undef SOCKET_SIZE_TYPE--- ./src/configure.in 1998/12/13 20:08:20 64.2
+++ ./src/configure.in 1999/01/19 00:37:39 64.2.1.1
@@ -688,6 +688,43 @@
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))+AC_MSG_CHECKING(whether 'long long' is 64 bits)
+AC_TRY_RUN([#include <stdio.h>
+typedef long long int64;
+#define INT64_FORMAT "%qd"
+
+int64 a = 20000001;
+int64 b = 40000005;
+
+int does_int64_work()
+{
+ int64 c,d,e;
+ char buf[100];
+
+ if (sizeof(int64) != 8)
+ return 0; /* doesn't look like the right size */
+
+ /* we do perfunctory checks on multiply, divide, sprintf, sscanf */
+ c = a * b;
+ sprintf(buf, INT64_FORMAT, c);
+ if (strcmp(buf, "800000140000005") != 0)
+ return 0; /* either multiply or sprintf is busted */
+ if (sscanf(buf, INT64_FORMAT, &d) != 1)
+ return 0;
+ if (d != c)
+ return 0;
+ e = d / b;
+ if (e != a)
+ return 0;
+ return 1;
+}
+main() {
+ exit(! does_int64_work());
+}],
+ [AC_DEFINE(HAVE_QUAD_INT_64) AC_MSG_RESULT(yes)],
+ AC_MSG_RESULT(no),
+ AC_MSG_RESULT(assuming not on target machine))
+
dnl Checks for library functions.
AC_FUNC_MEMCMP
AC_TYPE_SIGNAL
Holm Tiffe wrote:
Hi all,
Hi, Holm,
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
After a little fiddeling around with the configure script and
include/utils/int8.h, I've got the int8 type working.
Since I've read somtimes in this Mailinglists, that FreeBSD is one
of the development platforms for PostgreSQL, I wonder why PGSQL
doesn't support FreeBSD's own format ...
Here are the patches I've used to enable int8 support.
Since my patches modify configure.in, you'll need to install
autoconf and regenerate the configure script.
Hope this helps,
Kevin.
==============================================================
--- ./src/backend/port/snprintf.c 1998/12/25 02:20:41 64.2
+++ ./src/backend/port/snprintf.c 1999/01/19 00:37:40 64.2.1.1@@ -49,7 +49,7 @@
#include <sys/param.h>
/* IRIX doesn't do 'long long' in va_arg(), so use a typedef */
-#ifdef HAVE_LONG_LONG_INT_64
+#if defined(HAVE_LONG_INT_64) || defined(HAVE_LONG_LONG_INT) ||
defined(HAVE_QUAD_INT_64)
typedef long long long_long;
typedef unsigned long long ulong_long;
#endif
--- ./src/include/utils/int8.h 1998/09/11 17:16:11 64.2
+++ ./src/include/utils/int8.h 1999/01/19 00:37:41 64.2.1.1
@@ -35,11 +35,18 @@ #define INT64_FORMAT "%lld"
#else
+#ifdef HAVE_QUAD_INT_64
+/* We have working support for "long long", use that */
+typedef long long int64;
+
+#define INT64_FORMAT "%qd"
+#else
/* Won't actually work, but fall back to long int so that int8.c
compiles
*/
typedef long int int64; #define INT64_FORMAT "%ld"
#define INT64_IS_BUSTED
+#endif
#endif
#endif
--- ./src/include/config.h.in 1998/12/13 20:08:24 64.2
+++ ./src/include/config.h.in 1999/01/19 00:37:41 64.2.1.1
@@ -267,6 +267,9 @@
/* Set to 1 if type "long long int" works and is 64 bits */
#undef HAVE_LONG_LONG_INT_64+/* Set to 1 if type "long long" works and is 64 bits */
+#undef HAVE_QUAD_INT_64
+
/* Define as the base type of the last arg to accept */
#undef SOCKET_SIZE_TYPE--- ./src/configure.in 1998/12/13 20:08:20 64.2
+++ ./src/configure.in 1999/01/19 00:37:39 64.2.1.1
@@ -688,6 +688,43 @@
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))+AC_MSG_CHECKING(whether 'long long' is 64 bits)
+AC_TRY_RUN([#include <stdio.h>
+typedef long long int64;
+#define INT64_FORMAT "%qd"
+
+int64 a = 20000001;
+int64 b = 40000005;
+
+int does_int64_work()
+{
+ int64 c,d,e;
+ char buf[100];
+
+ if (sizeof(int64) != 8)
+ return 0; /* doesn't look like the right size */
+
+ /* we do perfunctory checks on multiply, divide, sprintf, sscanf */
+ c = a * b;
+ sprintf(buf, INT64_FORMAT, c);
+ if (strcmp(buf, "800000140000005") != 0)
+ return 0; /* either multiply or sprintf is busted
*/
+ if (sscanf(buf, INT64_FORMAT, &d) != 1)
+ return 0;
+ if (d != c)
+ return 0;
+ e = d / b;
+ if (e != a)
+ return 0;
+ return 1;
+}
+main() {
+ exit(! does_int64_work());
+}],
+ [AC_DEFINE(HAVE_QUAD_INT_64) AC_MSG_RESULT(yes)],
+ AC_MSG_RESULT(no),
+ AC_MSG_RESULT(assuming not on target machine))
+
dnl Checks for library functions.
AC_FUNC_MEMCMP
AC_TYPE_SIGNALImport Notes
Resolved by subject fallback
Kevin Lo <jwlo@ms11.hinet.net> writes:
While compiling of 6.4.2 I've realized that int8's are not supported
on FreeBSD by default. The Configure script looks if %ld or %lld
will do the job but FreeBSD is using %qd as the long long int format.
Here are the patches I've used to enable int8 support.
Actually, given the way that the 6.5 sources currently stand, the right
long-term solution is to make two separate tests: (1) does the compiler
do 64-bit arithmetic correctly, and if so then (2) does snprintf have a
working format for the chosen type. If (1) passes but (2) fails we have
a fallback: enable use of our own snprintf code. When I wrote the 6.4
configure test for int8, we hadn't yet developed that fallback, so there
wasn't much point in distinguishing compiler support from library
support. But now we should.
If we do it this way then it doesn't matter a whole lot whether "%qd" is
one of the tested alternatives or not ;-).
I will pursue fixing things that way in the 6.5 sources. In the
meantime, do we want to check Kevin's fixes into REL6_4, or is adding
int8 support for more machines too low-priority to justify taking any
chance of breaking 6.4.3?
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofSun07Mar1999125320+080036E2063F.3DFAB89A@ms11.hinet.net | Resolved by subject fallback
On Sun, 7 Mar 1999, Tom Lane wrote:
I will pursue fixing things that way in the 6.5 sources. In the
meantime, do we want to check Kevin's fixes into REL6_4, or is adding
int8 support for more machines too low-priority to justify taking any
chance of breaking 6.4.3?
Note that I commited int8 fixes to the v6.4.3 tree, and they are in the
current beta3 tar file...did this mid-last week...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
On Sun, 7 Mar 1999, Tom Lane wrote:
I will pursue fixing things that way in the 6.5 sources. In the
meantime, do we want to check Kevin's fixes into REL6_4, or is adding
int8 support for more machines too low-priority to justify taking any
chance of breaking 6.4.3?Note that I commited int8 fixes to the v6.4.3 tree, and they are in the
current beta3 tar file...did this mid-last week...
Did you also change the #ifdef line to include __NetBSD__ for the %qd
format? At least NetBSD/i386 uses that. Alpha might not, I'm not
fully certain, but I think it will work with %qd.
--Michael
Import Notes
Reply to msg id not found: TheHermitHackersmessageofSun7Mar1999190539-0400AST
Try what I just commited now...its only in v6.5 sources though...
I've modified it so that it checks for use of %lld, and if that fails,
check for use of %qd, before it falls back to our homebrew snprintf...
On 7 Mar 1999, Michael Graff wrote:
The Hermit Hacker <scrappy@hub.org> writes:
On Sun, 7 Mar 1999, Tom Lane wrote:
I will pursue fixing things that way in the 6.5 sources. In the
meantime, do we want to check Kevin's fixes into REL6_4, or is adding
int8 support for more machines too low-priority to justify taking any
chance of breaking 6.4.3?Note that I commited int8 fixes to the v6.4.3 tree, and they are in the
current beta3 tar file...did this mid-last week...Did you also change the #ifdef line to include __NetBSD__ for the %qd
format? At least NetBSD/i386 uses that. Alpha might not, I'm not
fully certain, but I think it will work with %qd.--Michael
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
Try what I just commited now...its only in v6.5 sources though...
I've modified it so that it checks for use of %lld, and if that fails,
check for use of %qd, before it falls back to our homebrew snprintf...
What I committed this afternoon will work on a %qd box, it'll just
choose to insert our homebrew snprintf instead of using the local
version.
Is it worth adding another test cycle to configure in order to use the
native snprintf on these boxes? There are not that many boxes that
use %qd; and it's not real clear that using our own snprintf is a loss
anyway.
Just my $0.02 ...
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofMon8Mar1999001820-0400Pine.BSF.4.05.9903080017301.393-100000@thelab.hub.org | Resolved by subject fallback
On Mon, 8 Mar 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Try what I just commited now...its only in v6.5 sources though...
I've modified it so that it checks for use of %lld, and if that fails,
check for use of %qd, before it falls back to our homebrew snprintf...What I committed this afternoon will work on a %qd box, it'll just
choose to insert our homebrew snprintf instead of using the local
version.Is it worth adding another test cycle to configure in order to use the
native snprintf on these boxes? There are not that many boxes that
use %qd; and it's not real clear that using our own snprintf is a loss
anyway.
In all cases, using a system function is preferable to a "home brew
solution"...as its then guaranteed to work, and work optimally, for that
system...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org