Horton
Menu

Thread

  1. int 8 on FreeBSD

    Holm Tiffe <holm@freibergnet.de> — 1999-03-03T07:28:16Z

    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/

  2. Re: [HACKERS] int 8 on FreeBSD

    Michael Graff <explorer@flame.org> — 1999-03-03T08:32:46Z

    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:

> 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 fr 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/

  3. Re: [HACKERS] int 8 on FreeBSD

    Marc Fournier <scrappy@hub.org> — 1999-03-03T12:11:57Z

    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

  4. Re: [HACKERS] int 8 on FreeBSD

    Holm Tiffe <holm@freibergnet.de> — 1999-03-03T12:38:25Z

    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/

  5. Re: [HACKERS] int 8 on FreeBSD

    Marc Fournier <scrappy@hub.org> — 1999-03-03T13:38:58Z

    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

  6. Re: [HACKERS] int 8 on FreeBSD

    Holm Tiffe <holm@freibergnet.de> — 1999-03-03T14:24:57Z

    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/

  7. Re: [HACKERS] int 8 on FreeBSD

    Marc Fournier <scrappy@hub.org> — 1999-03-03T14:39:59Z

    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

  8. Re: [HACKERS] int 8 on FreeBSD

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-03-03T14:49:20Z

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

  9. Re: [HACKERS] int 8 on FreeBSD

    Holm Tiffe <holm@freibergnet.de> — 1999-03-03T14:54:38Z

    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/

  10. Re: [HACKERS] int 8 on FreeBSD

    Holm Tiffe <holm@freibergnet.de> — 1999-03-03T15:05:24Z

    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/

  11. Re: [HACKERS] int 8 on FreeBSD

    Kevin Lo <kevlo@hello.com.tw> — 1999-03-07T04:47:49Z

    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