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