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

["Martin v. Löwis"]

>> 2. Don't use extension modules. Edit Modules/Setup to statically link
>>    all extension modules into the interpreter binary.
> This is the way. But how to do that?
> 
> Shell output:
> ../configure --disable-shared

--disable-shared should be the default, so you don't need to specify
it explicitly. It works fine for me on Linux, so if it crashes for
you, it is likely an Interix problem. Can you debug this?

Dynamic loading of extension modules is automatically detected;
it is active if the system is AIX, BeOS, HPUX, Darwin, atheos,
or if dlopen(3) has been found. If you explicitly want to disable
it, you can set DYNLOADFILE to dynload_stub.o in configure.
Not sure whether Interix has dlopen, but even if does, it should
do no harm to use it provided there aren't any modules to load.

> I assume the "Modules/<some more objects>" are the extension modules. To get
> them statically linked, the functions must be called somewhere. Statically
> linked = "Builtin modules"? You mean I should list all of these in
> "Modules/Setup"?

Exactly so. They are already listed - just uncomment them all
(with proper command line flags and libraries where necessary).

> FYI I got the "dynload_stub.c" compiled in.

Ok, so you don't have dynamic loading.

> BTW, shouldn't "--disable-shared" take care of this?

No, this talks only about libpythonxy.so.

> It's really very simple - I got LP64 libraries (Interix SDK). To get them to
> work with a LLP64 compiler I need explicit sized types in case of long.

I still don't understand. Are you *certain* that these are LP64
libraries? Can you kindly refer to some official document that says
Interix uses LP64 on AMD64?

And if so, how did Microsoft manage to build them, if their compiler
does not support LP64? (I see you kind of answer that below - although
I'm unsure what "translate all longs to long long means - you mean
literal text replacement?)

Methinks you should just activate the LP64 mode of VC 2005, and be
done (and no, I don't know how to do that :-)

> FYI: cc is a shell script wrapper of a x64 PE compiler, which in this case
> is the MS x64 compiler v 14.00.50727.762 - POSIX mode. It automatically
> translates all longs to long long in case of a 64bit compile. Thus, cc
> cannot easily be used in e.g. Visual Studio.

So don't use Visual Studio, then. What's wrong with the Makefile?

> Oh, it was never my intention to propose a change to the LLP64 model. And
> your right: All exports should be according to the LP64 model in case of a
> POSIX compile. One must follow some rules! But you must admit it's tempting
> with all these:
> #if SIZEOF_LONG > 4
> < get rid of the 64bit crap >
> #endif

My view would be different - I find it tempting not to use Interix,
let alone on AMD64...

> In my case the different paradigms are a real pain. I must take it into
> account all the time when porting. I can only hope people stop using <long>
> in favour of explicit sized types or types like size_t, intptr_t etc. I
> would love to see the damn thing obsolete.

You mean the long type? I see nothing wrong with it. The real fault here
is with Microsoft, who managed to provide a system for which they don't
provide a C compiler, but just a hack that looks like a C compiler from
remote.

Regards,
Martin