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
> struct s { char a; long b; };
> int main(int argc, char *argv[])
> {
> int array[offseto
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 cross-co
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 previo
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 vi
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 architecture
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
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 res
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 tho
