Re: Getting to universal binaries for Darwin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Getting to universal binaries for Darwin
Date: 2008-07-20 13:48:15
Message-ID: 28323.1216561695@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> 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 array[offsetof(struct s, b) - 5];

> return 0;
> }

> What happens if you run gcc -arch i386 -arch ppp64 on it? Does it require
> success on both output architectures?

Seems so. On a current MacBook Pro:

$ cat test.c
#include <stddef.h>

struct s { char a; long b; };

int main(int argc, char *argv[])
{
int array[offsetof(struct s, b) - 5];

return 0;
}
$ gcc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch i386 -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch x86_64 -c test.c
$ gcc -arch ppc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch ppc64 -c test.c
$ gcc -arch i386 -arch x86_64 -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
lipo: can't figure out the architecture type of: /var/folders/5M/5MGusdunEbWmuxTsRCYfbk+++TI/-Tmp-//ccfrarXl.out
$ gcc -arch i386 -arch ppc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
lipo: can't figure out the architecture type of: /var/folders/5M/5MGusdunEbWmuxTsRCYfbk+++TI/-Tmp-//ccFqrJgr.out
$

This doesn't look amazingly well tested though: what I suspect is
happening is that it runs N instances of the compiler (note multiple
errors in the last case) and then tries to sew their output together
with lipo, whether they succeeded or not. I'll bet the "can't figure
out" is reflecting not being able to make sense of a zero-length .o
file ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-07-20 15:27:06 Re: temp table problem
Previous Message Peter Eisentraut 2008-07-20 07:50:36 Re: Getting to universal binaries for Darwin