Hello Martin,
Thanks very much for answering.
> 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:
Aha, now it lightens a bit. As I understand, I will need a x86_64 PE GNU ld
to get this to work as intended - however, there is no such thing at this
moment.
> 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
...
ar cr libpython2.5.a Objects/<all objects>
ar cr libpython2.5.a Python/<all objects>
ar cr libpython2.5.a Modules/<some objects - main, config...>
ar cr libpython2.5.a Modules/<some more objects - threadmodule.o ...>
cc -o python \
Modules/python.o \
libpython2.5.a -lsocket -lm
CC='cc' LDSHARED='ld' OPT='-DNDEBUG -O' ./python -E ../setup.py build;;
Memory fault (core dumped)
make: *** [sharedmods] Error 139
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"? FYI I got the "dynload_stub.c" compiled in. BTW, shouldn't
"--disable-shared" take care of this?
> 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...
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.
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.
> 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.
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
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.
Cheers,
Erik
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
