Thread: 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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut <peter_e@gmx.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@gmx.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@gmx.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@gmx.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/