Message170643
Gripe: if you want a 64-bit, non-gcc (i.e. vendor's cc) build on a proprietary UNIX system (i.e. Solaris, HP-UX, AIX etc), "you're going to have a bad time".
Coercing a 64-bit build from a vendor's cc currently requires explicit CFLAGS/LDFLAGS/configure gymnastics for each platform. It's a pain.
Initial goal: use this issue to document the gymnastics.
Assumption: once all the different techniques are documented, it'll be easier to assess what changes would be appropriate to configure.in.
Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on an amd64 platform, you'll get a 64-bit build. This isn't the case for Solaris, HP-UX and AIX -- the default is always 32-bit. You need aforementioned gymnastics to coerce a 64-bit build.
Is this by design? If so, then I guess I'm proposing that ./configure should have a `--with-64`-type argument that'll generate a 64-bit build.
If not, then we need to decide whether to change the default behavior such that ./configure always generates a 64-bit build if you're on a 64-bit platform -- if you want a 32-bit build, you need to explicitly tell ./configure (i.e. --with-32).
Changing the default is probably only viable for 3.4 onwards. It'd be nice if 2.7->3.3 had generic configure support for 64-bit builds though (via --with-64).
XXX TODO for trent: review autoconf's offerings... getting 64-bit builds from vendor cc's can't be that unusual. |
|
Date |
User |
Action |
Args |
2012-09-18 13:40:35 | trent | set | recipients:
+ trent |
2012-09-18 13:40:35 | trent | set | messageid: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> |
2012-09-18 13:40:35 | trent | link | issue15963 messages |
2012-09-18 13:40:34 | trent | create | |
|