[Python-Dev] x86_64 Interix - Advise needed on size of long

["Martin v. Löwis"]

> My first attempt to build failed due to the makefile insisted on linking as
> shared libraries (works only in x86 with GNU ld). Tried autoreconf to get
> rid of libtool - no luck.
> Q1: Is the static build broken?
> Q2: Anyone have a useable Makefile.am?

Are you sure you are talking about Python as released? It uses neither
automake nor libtool (IMO, fortunately so).

As for the static vs. shared libpython: On Unix, Python is typically
built as a single executable (only linked shared with the system
libraries). The challenge is then with extension modules, which are
shared libraries. In particular, it is a challenge that those want
to find symbols defined in the executable, without being linked with
it. So you have three options:

1. If you use a sane binary format (such as ELF), symbol resolution
   considers symbols defined by the executable for use in shared
   libraries. This is necessary to support standard C, as you want
   to be able to redefined malloc(3) in the executable, and then all
   libraries should use your malloc implementation; it comes handy
   for Python's extensions. By this definition, Portable Executable (PE)
   is insane.
2. Don't use extension modules. Edit Modules/Setup to statically link
   all extension modules into the interpreter binary.
3. Arrange to make the interpreter a shared library (libpythonxy.so),
   then link all extension modules against it.

> There are 2 choices: All longs to 64bit (LP64 model) or all to 32bit (LLP64
> model). Since Interix use LP64 the first alternative would be logic, but
> considering compatibility with the Windows DLL, performance(?) and whatever,
> I choosed the latter. A choice which later would turn me into trouble.

I don't see the compatibility issue. You aren't going to use Win32
extensions in the Interix interpreter, are you? So why care about Win32?

> Here's how I am reasoning:
> 
> x64 Windows DLL = LLP64 model => sizeof(long) = 4
> x86_64 Interix  = LP64 model  => sizeof(long) = 8

I think we agree that the Windows model is insane, also. A good 64-bit
platform has sizeof(long)==8.

> So, since the Windows build works, basically all long types in the code are
> 32bit (or at least works if they are 32bit).

Right. However, LP64 also works with Python, and has been for many more
years.

> 64bit dependent variables like
> pointers have already been taken care of. Right? While it sounds reasonable
> as long as one are consistent, it's actually quite difficult to get it right
> (and a lot of work).
> 
> To be precise, would this be OK?
> long PyInt_AsLong(PyObject *);
> change to:
> int32_t PyInt_AsLong(PyObject *);
> or
> unsigned long PyOS_strtoul(char*, char**, int);
> to:
> uint32_t PyOS_strtoul(char*, char**, int);

OK in what sense? You making these changes locally? You can make
whatever changes you please; this is free software. I can't
see *why* you want to make all these changes, but if you so
desire...

This becoming part of Python? No way. It is intentional that
PyInt_AsLong returns long (why else would the function be called
this way?), and it is also intentional that the int type has
its internal representation as a long.

Likewise for strtoul: this function is defined to return long,
for whatever definition long has on a platform.

Regards,
Martin