This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Issue with _PyLong_Format while trying to build Python on HP-UX itanium
Type: compile error Stage:
Components: Build Versions: Python 3.1
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, loewis, paulh_irl
Priority: normal Keywords:

Created on 2009-11-26 12:23 by paulh_irl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg95741 - (view) Author: Paul H (paulh_irl) Date: 2009-11-26 12:23
Hello all,

First post here so go easy on me please! And please bear in mind I am
not a C programmer, just a unix admin trying to build python as an
option for other programmers to use.

I am trying to build Python 3.1.1 on HP-UX itanium. OS and compiler
details are as follows:

HP-UX <hostname> B.11.31 U ia64 2812253632 unlimited-user license
aCC: HP C/aC++ B3910B A.06.23 [May 18, 2009]

So far, with the help of this forum and documentation from this and
previous versions of Python, I have been working through the process as
follows:

export CC="/opt/aCC/bin/aCC -Ae +DD64"
export CFLAGS="-Ae +DD64"
export CXX="/opt/aCC/bin/aCC -Ae"
export CXXFLAGS="-Ae +DD64"
export LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
./configure --prefix=<my target>/python/3.1.1 --without-gcc

unset CC CFLAGS CXX CXXFLAGS LDFLAGS
make

I've been working through the various errors I've been getting as best I
can and have hit one that I don't think I can progress:

"Python/../Objects/stringlib/formatter.h", line 1369: error #2140: too many
          arguments in function call
      return _PyLong_Format(value, base, 0, 1);

It looks like _PyLong_Format is defined in Objects/longobject.c.

Any ideas on how to progress this one, or indeed any tips to get a
successful build on my architecture, would be much appreciated.

Many thanks,
Paul.
msg95742 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-11-26 12:37
For 3.1, line 1369 of Python/../Objects/stringlib/formatter.h should not
be used. There's a #if on line 1359 that prevents the long_format
function from being used. Could you investigate why that #if is using
the wrong value?
msg95743 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-11-26 12:46
To elaborate on Eric's suggestion, put a single line

top PY_VERSION_HEX bottom

right above the line 

#if PY_VERSION_HEX >= 0x03000000

Then add the flag that produces preprocessor output to the compiler line
(copy the compiler line literally from the build process). Most likely,
you'll have to replace the -c option with either -P or -E; search the
output for the top/bottem pattern, and report the value of PY_VERSION_HEX.
msg95745 - (view) Author: Paul H (paulh_irl) Date: 2009-11-26 15:19
Hi all,

Many thanks for the tips, and for the super-quick responses also! 

Yes indeed, what is happening here is that PY_VERSION_HEX is not being
evaluated correctly. In fact what appears to be happening is that
Include/patchlevel.h is not being considered in the compile despite
"-IInclude" being on the compiler command line. Perhaps I have a
compiler issue. I'll work it from here.

Thanks again for your help.
Paul.
msg95746 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-11-26 15:57
I'm going to close this, but if you find the problem (and especially if
you develop a patch to resolve it), please post back here.
History
Date User Action Args
2022-04-11 14:56:55adminsetgithub: 51647
2009-11-26 15:57:58eric.smithsetstatus: open -> closed

messages: + msg95746
2009-11-26 15:19:04paulh_irlsetmessages: + msg95745
2009-11-26 12:46:40loewissetnosy: + loewis
messages: + msg95743
2009-11-26 12:37:36eric.smithsetnosy: + eric.smith
messages: + msg95742
2009-11-26 12:23:47paulh_irlcreate