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