Building Python with VC8 on x64 Vista

Discussion in 'Python' started by danfike@gmail.com, Sep 20, 2007.

  1. Guest

    Hi all,

    So I'm working on a C++ application that will eventually embed or
    extend Python using Boost.Python, but I first need to get Python
    compiled correctly for my platform. I've got a Windows Vista 64-bit
    machine with a Core 2 processor, and I'm compiling with a VC8.

    I downloaded the Python 2.5.1 source from python.org, and I opened the
    Visual Studio solution file that was in the PCbuild8 directory. I
    created a new x64 platform and managed to successfully compile the
    'pythoncore' and 'python' projects (both in Debug and Release
    configurations), resulting in working executables. (Aside: When
    launched, the python console says "Python 2.5.1 [MSC v.1400 64 bit
    (AMD64)] on win32" up top. Does that seem right?)

    So, this program I'm writing with Boost.Python (that worked correctly
    on x86 with home-built libraries) won't compile with these x64
    libraries. I keep getting 'unresolved external symbols.' But, I'm
    certain I'm linking in the library correctly. Here's a snippet from
    the output (with /verbose:lib) when compiling:

    1>Searching libraries
    1> <snip>
    1> Searching ..\..\..\3rdParty\boost_1_34_0\lib_x64\libboost_python-
    vc80-mt-gy-1_34.lib:
    1> <snip>
    1> Searching ..\..\..\3rdParty\Python25\libs_x64\python25_d.lib:
    1>Finished searching libraries
    1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    _Py_NoneStruct
    1>vector_py.obj : error LNK2001: unresolved external symbol
    _Py_NoneStruct
    1>volume_py.obj : error LNK2001: unresolved external symbol
    _Py_NoneStruct
    1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    _Py_RefTotal
    1>vector_py.obj : error LNK2001: unresolved external symbol
    _Py_RefTotal
    1>volume_py.obj : error LNK2001: unresolved external symbol
    _Py_RefTotal
    1>volume_py.obj : error LNK2001: unresolved external symbol
    PyExc_IndexError

    If I switch to the Release configuration, I see fewer errors:

    1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    _Py_NoneStruct
    1>volume_py.obj : error LNK2001: unresolved external symbol
    PyExc_IndexError

    Note that none of my own code is Debug-specific. Also, the code in my
    files is correct, because (as stated above), it worked fine for x86.

    Though I don't know how useful it is, I did open the python libraries
    in wordpad, and though most of the file wasn't legible, I did find
    strings "Py_NoneStruct," "Py_RefTotal," and "PyExc_IndexError."


    I suspect that I set up my "x64" platform configuration incorrectly,
    or missed something. It's basically the same as the Win32
    configuration, except with the /MACHINE:X64 flag instead of /
    MACHINE:X86. One of the things I'm noticing just now, as I post this,
    is that the preprocessor flag "WIN32" is still defined in the x64
    configuration. Maybe if I change that to "WIN64," I'll have better
    luck.

    Any advice you have on what the "correct" way to do this is would be
    appreciated.

    -Dan
     
    , Sep 20, 2007
    #1
    1. Advertising

  2. Guest

    On Sep 20, 9:45 am, wrote:
    > Hi all,
    >
    > So I'm working on a C++ application that will eventually embed or
    > extend Python using Boost.Python, but I first need to get Python
    > compiled correctly for my platform. I've got a Windows Vista 64-bit
    > machine with a Core 2 processor, and I'm compiling with a VC8.
    >
    > I downloaded the Python 2.5.1 source from python.org, and I opened the
    > Visual Studio solution file that was in the PCbuild8 directory. I
    > created a new x64 platform and managed to successfully compile the
    > 'pythoncore' and 'python' projects (both in Debug and Release
    > configurations), resulting in working executables. (Aside: When
    > launched, the python console says "Python 2.5.1 [MSC v.1400 64 bit
    > (AMD64)] on win32" up top. Does that seem right?)
    >
    > So, this program I'm writing with Boost.Python (that worked correctly
    > on x86 with home-built libraries) won't compile with these x64
    > libraries. I keep getting 'unresolved external symbols.' But, I'm
    > certain I'm linking in the library correctly. Here's a snippet from
    > the output (with /verbose:lib) when compiling:
    >
    > 1>Searching libraries
    > 1> <snip>
    > 1> Searching ..\..\..\3rdParty\boost_1_34_0\lib_x64\libboost_python-
    > vc80-mt-gy-1_34.lib:
    > 1> <snip>
    > 1> Searching ..\..\..\3rdParty\Python25\libs_x64\python25_d.lib:
    > 1>Finished searching libraries
    > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    > _Py_NoneStruct
    > 1>vector_py.obj : error LNK2001: unresolved external symbol
    > _Py_NoneStruct
    > 1>volume_py.obj : error LNK2001: unresolved external symbol
    > _Py_NoneStruct
    > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    > _Py_RefTotal
    > 1>vector_py.obj : error LNK2001: unresolved external symbol
    > _Py_RefTotal
    > 1>volume_py.obj : error LNK2001: unresolved external symbol
    > _Py_RefTotal
    > 1>volume_py.obj : error LNK2001: unresolved external symbol
    > PyExc_IndexError
    >
    > If I switch to the Release configuration, I see fewer errors:
    >
    > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    > _Py_NoneStruct
    > 1>volume_py.obj : error LNK2001: unresolved external symbol
    > PyExc_IndexError
    >
    > Note that none of my own code is Debug-specific. Also, the code in my
    > files is correct, because (as stated above), it worked fine for x86.
    >
    > Though I don't know how useful it is, I did open the python libraries
    > in wordpad, and though most of the file wasn't legible, I did find
    > strings "Py_NoneStruct," "Py_RefTotal," and "PyExc_IndexError."
    >
    > I suspect that I set up my "x64" platform configuration incorrectly,
    > or missed something. It's basically the same as the Win32
    > configuration, except with the /MACHINE:X64 flag instead of /
    > MACHINE:X86. One of the things I'm noticing just now, as I post this,
    > is that the preprocessor flag "WIN32" is still defined in the x64
    > configuration. Maybe if I change that to "WIN64," I'll have better
    > luck.
    >
    > Any advice you have on what the "correct" way to do this is would be
    > appreciated.
    >
    > -Dan


    I've tried re-building my libraries from the latest revision (58225),
    using the solution in the PCbuild8 folder. I had no problems getting
    the python25[_d].lib to compile, but I still get these symbol errors
    when I try to link with the library.

    -Dan
     
    , Sep 21, 2007
    #2
    1. Advertising

  3. Re: Building Python with VC8 on x86-64 Vista

    In message <>,
    wrote:

    > Though I don't know how useful it is, I did open the python libraries
    > in wordpad, and though most of the file wasn't legible, I did find
    > strings "Py_NoneStruct," "Py_RefTotal," and "PyExc_IndexError."


    Do you have some equivalent of the "nm" command for dumping the symbols and
    their definitions in the library?
     
    Lawrence D'Oliveiro, Sep 22, 2007
    #3
  4. > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    > _Py_NoneStruct


    Could it be that py_dyn_test.obj is a x86 (not AMD64) object
    file? Run dumpbin.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Sep 22, 2007
    #4
  5. Guest

    On Sep 22, 10:08 am, "Martin v. Löwis" <> wrote:
    > > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol
    > > _Py_NoneStruct

    >
    > Could it be that py_dyn_test.obj is a x86 (not AMD64) object
    > file? Run dumpbin.


    Hmm - I've never used dumpbin, but I think I like it.

    It doesn't look like these are x86, though. See below:

    D:\....\py_dyn_test\x64\Debug>dumpbin /HEADERS py_dyn_test.obj
    Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
    Copyright (C) Microsoft Corporation. All rights reserved.


    Dump of file py_dyn_test.obj

    File Type: COFF OBJECT

    FILE HEADER VALUES
    8664 machine (x64)
    ....


    D:\....\3rdParty\Python25\libs>dumpbin /HEADERS python25_d.lib
    Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
    Copyright (C) Microsoft Corporation. All rights reserved.


    Dump of file python25_d.lib

    File Type: LIBRARY

    FILE HEADER VALUES
    8664 machine (x64)
    3 number of sections
    46F3CED2 time date stamp Fri Sep 21 09:01:54 2007
    113 file pointer to symbol table
    8 number of symbols
    0 size of optional header
    0 characteristics

    <snip>

    Version : 0
    Machine : 8664 (x64)
    TimeDateStamp: 46F3CED2 Fri Sep 21 09:01:54 2007
    SizeOfData : 0000001E
    DLL name : python25_d.dll
    Symbol name : _Py_NoneStruct
    Type : data
    Name type : name
    Hint : 900
    Name : _Py_NoneStruct

    <etc>
     
    , Sep 24, 2007
    #5
  6. > It doesn't look like these are x86, though.

    Ok. Can you then check symbol lists also?: undefined
    symbols in the object file, and defined symbols in the
    library, wrt. PyExc_IndexError (say).

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Sep 24, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Howard Lightstone

    Building extensions with vc8

    Howard Lightstone, Jan 22, 2007, in forum: Python
    Replies:
    1
    Views:
    291
    =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=
    Jan 22, 2007
  2. Replies:
    8
    Views:
    666
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Apr 11, 2007
  3. SiWi
    Replies:
    2
    Views:
    1,164
  4. Edward Diener
    Replies:
    3
    Views:
    925
    Edward Diener
    Jul 20, 2010
  5. mysiar

    Vista x64 + DBD::Pg driver

    mysiar, Jan 26, 2009, in forum: Perl Misc
    Replies:
    7
    Views:
    112
    mysiar
    Jan 30, 2009
Loading...

Share This Page