Fix for cross compilation

In 8.0, PostgreSQL lost its previously postulated ability to be
cross-compiled and it turns out some people actually used that, so
here's an attempt to fix it.

The problem is that the program zic in src/timezone/ is built and run
during the build process, which doesn't work if it's compiled by a
cross-compiler.

The standard way to go about this in autotools land (references: gcc,
binutils) is to introduce a second variable CC_FOR_BUILD that is set to
a native compiler. There is no particular way to determine this
variable; it's passed by the user or defaults to $CC. This variable is
then used in place of CC to build programs that are compiled and run
during the build.

The problem is that native compilations cannot rely on things that the
build system normally provides because the tests are run for the target
system, not the build system. It can be assumed that the compilers are
of the same kind, so using CFLAGS etc. is OK. But one cannot rely on
libraries for example without entering a world of pain. Since most
programs that need native compilation are usually some small conversion
programs, this generally works out well anyway.

Attached is a patch that implements that principle for zic. zic can no
longer use libpgport, but the only thing it seems to use from there is
strerror() and I like to think that we can get away with that.

I haven't actually tried this out with a cross compilation since I'm not
set up for it, so if someone has an environment available, please give
this a try.

Comments?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

What about our threading configure test? That doesn't allow cross
compilation either, does it?

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> In 8.0, PostgreSQL lost its previously postulated ability to be
> cross-compiled and it turns out some people actually used that, so
> here's an attempt to fix it.
>
> The problem is that the program zic in src/timezone/ is built and run
> during the build process, which doesn't work if it's compiled by a
> cross-compiler.
>
> The standard way to go about this in autotools land (references: gcc,
> binutils) is to introduce a second variable CC_FOR_BUILD that is set to
> a native compiler. There is no particular way to determine this
> variable; it's passed by the user or defaults to $CC. This variable is
> then used in place of CC to build programs that are compiled and run
> during the build.
>
> The problem is that native compilations cannot rely on things that the
> build system normally provides because the tests are run for the target
> system, not the build system. It can be assumed that the compilers are
> of the same kind, so using CFLAGS etc. is OK. But one cannot rely on
> libraries for example without entering a world of pain. Since most
> programs that need native compilation are usually some small conversion
> programs, this generally works out well anyway.
>
> Attached is a patch that implements that principle for zic. zic can no
> longer use libpgport, but the only thing it seems to use from there is
> strerror() and I like to think that we can get away with that.
>
> I haven't actually tried this out with a cross compilation since I'm not
> set up for it, so if someone has an environment available, please give
> this a try.
>
> Comments?
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The problem is that the program zic in src/timezone/ is built and run
> during the build process, which doesn't work if it's compiled by a
> cross-compiler.

Why don't we instead arrange to run it during install?

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. Also there's the problem
that it is reading a pg_config.h that is definitely platform-specific.

BTW, the truth of the matter is that we've never supported
cross-compilation; see all the AC_TRY_RUN operations in configure.

regards, tom lane

Am Montag, 30. Mai 2005 20:11 schrieb Tom Lane:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > The problem is that the program zic in src/timezone/ is built and run
> > during the build process, which doesn't work if it's compiled by a
> > cross-compiler.
>
> Why don't we instead arrange to run it during install?

It does currently run during the install. How does that help?

> 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. Also there's the problem
> that it is reading a pg_config.h that is definitely platform-specific.

Well, that is true. Bummer.

> BTW, the truth of the matter is that we've never supported
> cross-compilation; see all the AC_TRY_RUN operations in configure.

They all have (or should have) fall-back values for cross-compilation. Else,
those who complain about zic would have never gotten there.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Montag, 30. Mai 2005 20:11 schrieb Tom Lane:
>> Why don't we instead arrange to run it during install?

> It does currently run during the install. How does that help?

I'm sorry, I meant "later than it is now". Presumably the person doing
the cross-compile has *some* access to the target hardware and could run
the zic program on that hardware. During the regular install step of a
cross-compile build, instead of trying to run zic, we'd have to copy
zic, the timezone source data files, and probably a small shell script
into the install tree. Then at some later point the user would have to
invoke the shell script on the target hardware in order to finish the
installation. Kinda messy, I agree, but at least it will work reliably.

regards, tom lane

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

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

Tom Lane wrote:
> 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.

With that in mind, I have installed the original cross compilation patch
(with CC_FOR_BUILD). I realize that the inclusion of pg_config.h is
technically wrong, but AFAICT zic doesn't really make use of that
(e.g., int64 is not used to create the output files). I think this
should be enough to get interested cross compilers started, and we will
address specific problems as we see them. I guess a significant share
only want libpq anyway.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/