[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

New submission from Trent Nelson:

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.

----------
assignee: trent
components: Build
messages: 170643
nosy: trent
priority: low
severity: normal
status: open
title: Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).
type: enhancement
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15963>
_______________________________________