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

[Tasos Vogiatzoglou]

Hello Paolo,

Dunno if I am in the correct direction but till now I found two things

1) test_genc was throwing an error on fixup_c_type (complaining about
conflicting field type between HLOCAL and pointer to char array) so I
changed it to an opaque pointer (and the HANDLE type)

2) test_genc passed the tests, so the next step was to change the env
to use the 64bit libs changing from vsvars32.bat to vcvarsall.bat with
amd64 param in translator/platform/windows.py # _get_msvc_env(vsver):

After that change I had lot's of linking issues like

[platform:ERROR] testing_25.obj : error LNK2019: unresolved external
symbol __imp_Py_BuildValue referenced in function malloc_counters
[platform:ERROR] testing_25.obj : error LNK2019: unresolved external
symbol __imp_PyMethod_New referenced in function gencfunc_descr_get
[platform:ERROR] testing_25.obj : error LNK2019: unresolved external
symbol __imp__Py_NoneStruct referenced in function gencfunc_descr_get

Any idea ?

Thanks,
Tasos



On Wed, Feb 2, 2011 at 1:35 AM, Paolo Giarrusso
<pgiarrusso at mathematik.uni-marburg.de> wrote:
> 2011/2/1 René Dudfield <renesd at gmail.com>:
>> Hi,
>>
>> A naive guess would be the different sizes between 64bit windows, and
>> 64 bit linux?  (long int is 32bit on windows and 64bit on linux)
>>
>> From http://en.wikipedia.org/wiki/64-bit
>>
>> 64-bit data models
>> Data model      short (integer) int     long (integer)  long
>> long    pointers/size_t Sample operating systems
>> LLP64/
>> IL32P64 16      32      32      64      64      Microsoft Windows (X64/IA-64)
>> LP64/
>> I32LP64 16      32      64      64      64      Most Unix and Unix-like systems, e.g. Solaris,
>> Linux, and Mac OS X
>> ILP64   16      64      64      64      64      HAL Computer Systems port of Solaris to SPARC64
>> SILP64  64      64      64      64      64      Unicos
>
> From what Amaury said, you need to identify places where long is used
> and it is assumed that it has 64bits. A first guess, in general, is
> that _every_ use of long assumes it to be 64bit on 64bits systems.
>
> What about using intptr_t (or uintptr_t) from stdint.h? IOW, you'd
> simply replace long by this type everywhere, including in functions
> which generate C code through some library. I don't know the details,
> could somebody help here?
> IIRC this header was introduced in C99, and for sure this type is
> optional - i.e., it must be declared if it is available at all.
>
> Of course, there might be systems where this type is not available, so
> you need to provide a fallback (in a configure-like fashion). If this
> header is available on (modern) Windows environments (the only system
> where long is 32 bits), using "long" as fallback is safe.
>
> Cheers,
> --
> Paolo Giarrusso - Ph.D. Student
> http://www.informatik.uni-marburg.de/~pgiarrusso/
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev