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 <rep...@bugs.python.org> <http://bugs.python.org/issue15963> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
