Re: [HACKERS] DEC Alpha and HAVE_INT_TIMEZONE

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