Fix for cross compilation - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Fix for cross compilation
Date
Msg-id 200505301936.34657.peter_e@gmx.net
Whole thread Raw
Responses Re: Fix for cross compilation
Re: Fix for cross compilation
List pgsql-hackers
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/

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: US Goverment and Patents
Next
From: Peter Eisentraut
Date:
Subject: Autoconf update?