Horton
Menu

Thread

  1. DEC Alpha and HAVE_INT_TIMEZONE

    Dwayne Bailey <dwayne@mika.com> — 1998-03-20T14:55:08Z

    -----BEGIN PGP SIGNED MESSAGE-----

I've finally figured out why the Alpha fails when
HAVE_INT_TIMEZONE is defined.  As far as I'm concerned, somebody
at DEC should be shot.  The problem has nothing to do with
postgresql code.  The symbol 'timezone' is defined in two
different libraries, as two very different things!  libc.a
defines it as a global variable of type long, as documented in
the timezone(3) manpage.  However, libbsd.a defines a function
named timezone.  Since we link explicitly to -lbsd, guess which
definition gets linked into the program?  We're using the address
of that function as our timezone offset.  Well, the low four
bytes of the address, anyway.

As far as I can tell, we don't require any of the routines used
in libbsd.a.  I'm about to do some more testing to confirm this,
so hopefully a patch will be on its way soon.  Up to this point,
all I've recompiled under this new model is postgres, which links
fine, and runs without error.  The only failure on the date tests
that I noticed seemed to be using PST when it should have been
PDT.  I suspect that's an artifact of where I am (Michigan)
which, according to the /etc/zoneinfo/localtime source, didn't
observe DST between 1968 and 1973.

- --
Dwayne Bailey                   + WHAT is your name? Sir Galahad
MIKA Systems, Bingham Farms, MI + WHAT is your quest? I Seek the Holy Grail
dwayne@mika.com                 + What is your favorite color?
http://www.mika.com/~dwayne     +    Blue ... no, Yelloooooooooooooooooow
            finger dwayne@mika20.mika.com for PGP Public Key


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNRKDVKA2uleK7maRAQE3AQMAmJ41hAwHc/H1m+8XxoxCxwvxcS2S3Eki
fDQI7Bhd2QAPM8O8ufUaCejmSEbc2cBrJrYETukXzaQ9WdqcD1wZydLQv9h6i/4i
+g8lq48LxkBYT5QDlW3glHL7uNV+X6YS
=XQms
-----END PGP SIGNATURE-----

  2. Re: [HACKERS] DEC Alpha and HAVE_INT_TIMEZONE

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-20T17:19:42Z

    > 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> I've finally figured out why the Alpha fails when
> HAVE_INT_TIMEZONE is defined.  As far as I'm concerned, somebody
> at DEC should be shot.  The problem has nothing to do with
> postgresql code.  The symbol 'timezone' is defined in two
> different libraries, as two very different things!  libc.a
> defines it as a global variable of type long, as documented in
> the timezone(3) manpage.  However, libbsd.a defines a function
> named timezone.  Since we link explicitly to -lbsd, guess which
> definition gets linked into the program?  We're using the address
> of that function as our timezone offset.  Well, the low four
> bytes of the address, anyway.

I assume they are supporting both uses for the symbol.  I recommend
hard-coding the stuff into the port, and hopefully it will work.  Please
send it patches soon.  If it is alpha-specific, we can fold it into the
mega-patch, because alpha was broken in 6.3 anyway.

> 
> As far as I can tell, we don't require any of the routines used
> in libbsd.a.  I'm about to do some more testing to confirm this,
> so hopefully a patch will be on its way soon.  Up to this point,
> all I've recompiled under this new model is postgres, which links
> fine, and runs without error.  The only failure on the date tests
> that I noticed seemed to be using PST when it should have been
> PDT.  I suspect that's an artifact of where I am (Michigan)
> which, according to the /etc/zoneinfo/localtime source, didn't
> observe DST between 1968 and 1973.

Yea, I see this sometimes too on BSDI.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

  3. Re: [HACKERS] DEC Alpha and HAVE_INT_TIMEZONE

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-21T04:42:24Z

    > > I've finally figured out why the Alpha fails when
> > HAVE_INT_TIMEZONE is defined.  As far as I'm concerned, somebody
> > at DEC should be shot.  The problem has nothing to do with
> > postgresql code.  The symbol 'timezone' is defined in two
> > different libraries, as two very different things!  libc.a
> > defines it as a global variable of type long, as documented in
> > the timezone(3) manpage.  However, libbsd.a defines a function
> > named timezone.  Since we link explicitly to -lbsd, guess which
> > definition gets linked into the program?  We're using the address
> > of that function as our timezone offset.  Well, the low four
> > bytes of the address, anyway.
> 
> I assume they are supporting both uses for the symbol.  I recommend
> hard-coding the stuff into the port, and hopefully it will work.  
> > As far as I can tell, we don't require any of the routines used
> > in libbsd.a.  I'm about to do some more testing to confirm this,
> > so hopefully a patch will be on its way soon.  Up to this point,
> > all I've recompiled under this new model is postgres, which links
> > fine, and runs without error.  The only failure on the date tests
> > that I noticed seemed to be using PST when it should have been
> > PDT.  I suspect that's an artifact of where I am (Michigan)
> > which, according to the /etc/zoneinfo/localtime source, didn't
> > observe DST between 1968 and 1973.
> 
> Yea, I see this sometimes too on BSDI.

One of the other ports (AIX?) had this problem and they could just
remove the libbsd from the link arguments.

                 - Tom