From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fix for cross compilation |
Date: | 2005-06-09 23:23:54 |
Message-ID: | 8035.1118359434@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> I'm not real thrilled with the notion of trying to use a zic built by
>> a different compiler; I think that will lead to all sorts of
>> problems, considering that the files it's meant to write are binary
>> and at least potentially architecture-specific.
> Btw., in light of that the time zone files shouldn't be installed in the
> "share" subtree. Are there any reasons not to put them to somewhere
> under "lib"?
Hmm ... I suppose the implication of that is that the upstream zic files
*are* architecture-independent, else people wouldn't keep them in /share;
and looking at the code, it does seem some effort is made in that
direction. We are probably going to change the file format at some
point to avoid Y2038 issues, but maybe we should commit to keeping them
architecture-independent. (I wonder what the zic guys have in mind for
Y2038...)
I'm not sure that that makes the cross-compilation zic situation any
better, though, since it's still using a pg_config.h that may be
intended for a different architecture ... and it's hard to write
architecture-independent code when your "typedef int64" is wrong :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Edmund Dengler | 2005-06-10 01:30:13 | INHERITS and planning |
Previous Message | Peter Eisentraut | 2005-06-09 23:03:12 | Workaround for cross-compilation |