[pypy-dev] Link errors while translating with VS2010 and 64bit

[Armin Rigo]

Hi Tasos,

On Wed, Feb 2, 2011 at 1:15 AM, Tasos Vogiatzoglou <tvoglou at gmail.com> wrote:
> You are right. My mistake. It was picking the 2.6 32bit python. Now is
> working and tests are passing

A few extra notes.  What is needed to make this work is three-fold:

* make sure that in the C code, "intptr_t" is generated instead of
"long" for lltype.Signed, and similarly "uintptr_t" instead of
"unsigned long" for lltype.Unsigned.  This involves mainly fixing
translator/c/primitive.py to declare types using "intptr_t" instead of
"long", and probably fixing a number of other uses of "long" in the
.py files in that directory.

* make sure that in the hand-written headers translator/c/src/*.h, we
use "intptr_t" instead of "long" whenever it's needed (mostly
everywhere, I suppose, but not absolutely everywhere, e.g. not in
calls to external C functions that are declared to take or return a
long).

The changes above should fix the generation of code.  Now the third
part is the longest, probably.  You need to distinguish the two types
used in RPython, which are lltype.Signed and rffi.LONG, and which are
equal so far.  Of course rffi.LONG should remain equivalent to the C
long.  This probably needs looking around in all modules and in
pypy/rlib/, to make sure that we use the correct one, either
lltype.Signed or rffi.LONG.  Fortunately, errors resulting from this
confusion will probably just give translation-time errors, so we can
fix the places one after the other.  But you need to carefully check
the declaration of external functions that are implemented in
translator/c/src/*.h, like pypy/module/signal/interp_signal.py (this
one happens to use mostly rffi.INT, so it should work right now, with
the exception of LONG_STRUCT that uses a lltype.Signed).


A bientôt,

Armin.