Am Sunday, 20. July 2008 schrieb Tom Lane:
* This disables AC_TRY_RUN tests, of course. The only adverse
consequence I noticed was failure to recognize that
-Wl,-dead_strip_dylibs is applicable, which is marginally annoying but
hardly fatal.
On the whole I still wouldn't trust
Peter Eisentraut [EMAIL PROTECTED] writes:
For example, I'm a bit curious on the following aspect. This program should
fail to compile on 32-bit platforms but succeed on 64-bit:
#include stddef.h
struct s { char a; long b; };
int main(int argc, char *argv[])
{
int
Tom Lane wrote:
The bad news is that if you only do that, only the arch that you
actually build on will work. We have configure set up to insert
various hardware-dependent definitions into pg_config.h and
ecpg_config.h, and if you don't have the right values visible for
each compilation, the
Adriaan van Os [EMAIL PROTECTED] writes:
Tom Lane wrote:
You can get around that by hacking up the generated config files
with #ifdef __i386__ and so on to expose the correct values of
the hardware-dependent symbols to each build. Of course you have
to know what the correct values are --- if
Tom Lane wrote:
You can get around that by hacking up the generated config files
with #ifdef __i386__ and so on to expose the correct values of
the hardware-dependent symbols to each build. Of course you have
to know what the correct values are --- if you don't have a sample
of each
Am Saturday, 19. July 2008 schrieb Tom Lane:
The bad news is that if you only do that, only the arch that you
actually build on will work. We have configure set up to insert
various hardware-dependent definitions into pg_config.h and
ecpg_config.h, and if you don't have the right values
Peter Eisentraut [EMAIL PROTECTED] writes:
I'd imagine a related problem are the run tests in configure. They will
produce results for the platform that you run configure on. More properly,
you should run configure in cross-compilation mode (twice, and then merge the
output, as previously
Awhile back we determined that the big stumbling block for building
Postgres universal binaries for OS X was that we were using ld
to produce intermediate SUBSYS.o files, and it didn't want to preserve
multi-architecture components of input .o files. Peter got rid of that
hack recently, so I
