New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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). #60167
Comments
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 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. |
On the s10 slave (Solaris 10/nitrogen) for 3.x: (cpython@nitrogen:ttypts/4) (Tue/12:32) .. |
Solaris 10 release (i.e. optimized) build requires the following: ../../src/configure --without-gcc CFLAGS="-v -fsimple=0 -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt -xmemalign=8s -xregs=frameptr -xtarget=native -xbuiltin=%all -library=sunperf" CPPFLAGS="-IInclude" OPT="" LDFLAGS="-v -fsimple=0 -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt -xmemalign=8s -xbuiltin=%all -xregs=frameptr -xtarget=native -library=sunperf" CC=/opt/solarisstudio12.3/bin/cc (Due to indirect linker invocation via cc, I'm purposely duplicating CFLAGS <-> LDFLAGS for now. I'll refine later.) |
I'm glad I found this. Without the long incantation _decimal is ./configure --without-gcc CFLAGS=-m64 LDFLAGS=-m64 ..., and that seems to trigger an optimizer bug that produces The line that Trent gave appears to work. |
Hello |
On Tue, Sep 18, 2012 at 06:40:35AM -0700, Trent Nelson wrote:
|
I spent a little time on this yesterday. Here's what I came up with. The idea is to have a standalone block in configure.ac that kicks in when --without-gcc is specified (or if $CC != "gcc") *IFF* CFLAGS/CPPFLAGS haven't been provided by the user. If they have, we warn, and skip the block. Rationale is wanting to cover two cases: a) experienced user consciously overriding our attempts at sensible defaults in that block, b) inexperienced user who has no clue what the sensible defaults are but has otherwise inadvertently set CFLAGS/CPPFLAGS (or perhaps just inherited such settings from their existing environment). So, here's what the "block" looks like currently, albeit just for IRIX at the moment (and this was against 2.7). I'll eventually expand it to cover Solaris/SPARC|AMD64, AIX, HP-UX (PA-RISC/IA64) and Tru64. (Also note the new +AC_MSG_CHECKING(for --enable-64bit)
+# If we're not using GCC, we're probably on a proprietary UNIX, relying
|
Without having reviewed the proposed change in detail, a couple of comments. On current OS X systems and others, the compiler could be clang which perhaps should be treated as gcc for most autoconf purposes. Also, why are we putting any effort into supporting IRIX anymore? Both IRIX and the MIPS processor lines it runs on was retired by SGI in 2007. That's why support for IRIX was pulled from Python 3. It's a dead end. |
On Thu, Dec 13, 2012 at 10:28:00PM -0800, Ned Deily wrote:
|
Trent, did the HPUX CFLAGS/LDFLAGS change on the buildbots? I think Perhaps -AC99 or something like that is missing. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: