64-bit Windows Phoenix build?

I found Phoenix builds at http://wxpython.org/Phoenix/snapshot-builds, but the Windows builds are 32-bit. Is there somewhere a Windows build for 64-bit Python? I’m ignorant about SVN; what would I need to do to build from source? (I do routinely compile on Windows – I just need to know how to get a tarball with build instructions.)

Hi Bruce,

I found Phoenix builds at Index of /Phoenix/snapshot-builds, but
the Windows builds are 32-bit. Is there somewhere a Windows build for 64-bit
Python? I'm ignorant about SVN; what would I need to do to build from
source? (I do routinely compile on Windows -- I just need to know how to get
a tarball with build instructions.)

Currently there are no 64 bit builds for Phoenix on Windows, although
I am sure it is on Robin's todo list. Normally I build it myself,
doing the following:

0. Create two parallel folders called "wxWidgets" and "wxPython";

1. Download and install TortoiseSVN (Downloads · TortoiseSVN);

2. Download and install Cygwin (Cygwin Installation);

3. Download and install Doxygen
(http://www.stack.nl/~dimitri/doxygen/download.html);

4. I f you want to build the documentation locally, download and
install GraphViz (https://graphviz.org/download/);

5. Checkout[1] the wxWidgets source code from:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk

6. Checkout the Phoenix source code from:

http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/

7. You might have to set some PATH stuff for the build system to be
able to find the Visual Studio compiler/linker, these are the settings
on my machine (adjust accordingly):

set PATH=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\bin\amd64;C:\Python27;C:\Program Files
(x86)\Graphviz2.27\bin;C:\Program Files
(x86)\doxygen\bin;C:\cygwin\bin;C:\Python27\Scripts;C:\Program
Files\Microsoft SDKs\Windows\v7.0\Bin\X64
set LIB=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\lib\amd64;C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64
set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\include;C:\Program Files\Microsoft
SDKs\Windows\v7.0\Include;C:\Python27\include

8. From a DOS command window, move to the Phoenix folder and issue
*one* of the following commands:

# If you don't need the documentation locally:
python -u build.py 2.7 clean dox touch etg --nodoc sip build_wx build_py

# If you need the documentation locally:
python -u build.py 2.7 clean dox touch etg sip build_wx build_py

If you wish to build for Python versions other than 2.7, change the
"2.7" part to whatever you wish (>= 3.2). See the "build.py" script
help.

This should get you started, although using the default "build.py"
scripts you may also need waf_py (which is able to run
compilation/linking using multiple cores):

http://code.google.com/p/waf/

When it works, it works well, but it does so rarely for me: waf error
messages are pretty much useless and you may get entangled into a PATH
hell trying to make it work. If it doesn't work for you, in the
"build_py" method in the "build.py" file uncomment the "setup_py"
function call and comment out the "waf_py" function call.

[1] With TortoiseSVN, a "Checkout" is a simple matter of:

a) Right click the wxWidgets folder to pop up the context menu and
select the command TortoiseSVN → Checkout...
b) Insert the URL of repository as I mentioned above;
c) Click on "OK" (it may take a while).

Hope this helps.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

···

On 12 February 2013 05:54, Bruce Sherwood wrote:

Thanks very much for these details. To reduce how daunting this looks, some questions:

Why do I need Cygwin if I’m using Visual Studio (which I think is a requirement, because Python is built with Visual Studio)? I happen to have MSYS on my machine, but I hardly ever use it.

Presumably I don’t need Doxygen since I’m not generating documentation?

Sounds like I should disable the waf stuff, no?

···

On Tuesday, February 12, 2013 12:39:49 AM UTC-7, Infinity77 wrote:

  1. Download and install Cygwin (http://cygwin.com/install.html);

  2. Download and install Doxygen

(http://www.stack.nl/~dimitri/doxygen/download.html);

Andrea Gavana wrote:

Hi Bruce,

I found Phoenix builds at Index of /Phoenix/snapshot-builds, but
the Windows builds are 32-bit. Is there somewhere a Windows build for 64-bit
Python? I'm ignorant about SVN; what would I need to do to build from
source? (I do routinely compile on Windows -- I just need to know how to get
a tarball with build instructions.)

Currently there are no 64 bit builds for Phoenix on Windows, although
I am sure it is on Robin's todo list. Normally I build it myself,
doing the following:

0. Create two parallel folders called "wxWidgets" and "wxPython";

1. Download and install TortoiseSVN (Downloads · TortoiseSVN);

2. Download and install Cygwin (Cygwin Installation);

3. Download and install Doxygen
(http://www.stack.nl/~dimitri/doxygen/download.html);

This is no longer a prerequisite as build.py will download one into Phoenix/bin if it is not there already. This ensures that all builds will use the same version and not whatever the builder may happen to have installed.

4. I f you want to build the documentation locally, download and
install GraphViz (https://graphviz.org/download/);

5. Checkout[1] the wxWidgets source code from:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk

6. Checkout the Phoenix source code from:

http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/

7. You might have to set some PATH stuff for the build system to be
able to find the Visual Studio compiler/linker, these are the settings
on my machine (adjust accordingly):

set PATH=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\bin\amd64;C:\Python27;C:\Program Files
(x86)\Graphviz2.27\bin;C:\Program Files
(x86)\doxygen\bin;C:\cygwin\bin;C:\Python27\Scripts;C:\Program
Files\Microsoft SDKs\Windows\v7.0\Bin\X64
set LIB=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\lib\amd64;C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64
set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\include;C:\Program Files\Microsoft
SDKs\Windows\v7.0\Include;C:\Python27\include

8. From a DOS command window, move to the Phoenix folder and issue
*one* of the following commands:

# If you don't need the documentation locally:
python -u build.py 2.7 clean dox touch etg --nodoc sip build_wx build_py

# If you need the documentation locally:
python -u build.py 2.7 clean dox touch etg sip build_wx build_py

If you wish to build for Python versions other than 2.7, change the
"2.7" part to whatever you wish (>= 3.2). See the "build.py" script
help.

This should get you started, although using the default "build.py"
scripts you may also need waf_py (which is able to run
compilation/linking using multiple cores):

http://code.google.com/p/waf/

Again, build.py will download waf to Phoenix/bin if needed.

When it works, it works well, but it does so rarely for me: waf error
messages are pretty much useless and you may get entangled into a PATH
hell trying to make it work. If it doesn't work for you, in the
"build_py" method in the "build.py" file uncomment the "setup_py"
function call and comment out the "waf_py" function call.

What kinds of errors are you seeing from waf? I'd like to eventually make setup.py actually delegate to waf or perhaps just build.py for the build steps if it is invoked with a build command. Then the real build stuff can be only in waf and setup.py can focus on things like installation, making eggs, or other distutils/setuptools kinds of things.

···

On 12 February 2013 05:54, Bruce Sherwood wrote:

--
Robin Dunn
Software Craftsman

Bruce Sherwood wrote:

Thanks very much for these details. To reduce how daunting this looks,
some questions:

Why do I need Cygwin if I'm using Visual Studio (which I think is a
requirement, because Python is built with Visual Studio)? I happen to
have MSYS on my machine, but I hardly ever use it.

It's not for the cygwin or mingw32 compilers that it is needed, but for some of the other command line tools. If your MSYS is accessible on the PATH then that may be enough.

Presumably I don't need Doxygen since I'm not generating documentation?

It is needed to generate the XML used to feed API definitions to the Phoenix code generation tools.

Sounds like I should disable the waf stuff, no?

Try it. Waf is being used on all the buildbots and all my development machines, and is the way I want to move to in the future. If there are problems I'd like to iron them out.

···

--
Robin Dunn
Software Craftsman

Thanks to the very detailed instructions Andrea offered, I got quite a ways in building Phoenix for 64-bit Windows. However, at the end of the build I got the following error, despite which there is a folder named “wx”. Did I succeed or not?

Running command: build_wx

Command 'C:\Python32\python.exe -c "import distutils.msvc9compiler as msvc; mc =

msvc.MSVCCompiler(); mc.initialize(); print(mc.cc)"’ failed with exit code 1.

Traceback (most recent call last):

File “”, line 1, in

File “C:\Python32\lib\distutils\msvc9compiler.py”, line 371, in initialize

vc_env = query_vcvarsall(VERSION, plat_spec)

File “C:\Python32\lib\distutils\msvc9compiler.py”, line 287, in query_vcvarsal

l

raise ValueError(str(list(result.keys())))

ValueError: [‘path’, ‘include’, ‘lib’]

Finished command: build_wx (0.390s)

Also, am I supposed to do some kind of build operation in the parallel wxWidgets folder? Or is that folder there for the use of the Phoenix build? The resulting wx folder is only about 10 MB, whereas the 32-bit downloadable wx folders are about 35 MB, so I assume I haven’t succeeded.

Suggestions?

Bruce Sherwood wrote:

Thanks to the very detailed instructions Andrea offered, I got quite a
ways in building Phoenix for 64-bit Windows. However, at the end of
the build I got the following error, despite which there is a folder
named "wx". Did I succeed or not?

Do you actually have Visual Studio 2008? The complaint here is that the
LIBPATH environment variable was not found. The VS2008 vcvarsall.bat
batch file should have set LIBPATH for you.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

I do gave VS 2008 and use it, so presumably it’s a path mistake.

···

On Feb 14, 2013 11:58 AM, “Tim Roberts” timr@probo.com wrote:

Bruce Sherwood wrote:

Thanks to the very detailed instructions Andrea offered, I got quite a

ways in building Phoenix for 64-bit Windows. However, at the end of

the build I got the following error, despite which there is a folder

named “wx”. Did I succeed or not?

Do you actually have Visual Studio 2008? The complaint here is that the

LIBPATH environment variable was not found. The VS2008 vcvarsall.bat

batch file should have set LIBPATH for you.

Tim Roberts, timr@probo.com

Providenza & Boekelheide, Inc.

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Following Andrea’s instructions, I put the following into a .bat file and executed it. What’s missing/wrong with respect to LIBPATH? I’m guessing that LIBPATH means what LIB is set to, yes?

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64;C:\Python32;C:\Program Files (x86)\Graphviz2.27\bin;C:\Program Files (x86)\doxygen\bin;C:\cygwin\bin;C:\Python32\Scripts;C:\Program

Files\Microsoft SDKs\Windows\v7.0\Bin\X64

set LIB=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64;C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64

set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include;C:\Program Files\Microsoft SDKs\Windows\v7.0\Include;C:\Python32\include

C:\Python32\python -u build.py 3.2 clean dox touch etg --nodoc sip build_wx build_py

···

On Thu, Feb 14, 2013 at 11:58 AM, Tim Roberts timr@probo.com wrote:

Bruce Sherwood wrote:

Thanks to the very detailed instructions Andrea offered, I got quite a

ways in building Phoenix for 64-bit Windows. However, at the end of

the build I got the following error, despite which there is a folder

named “wx”. Did I succeed or not?

Do you actually have Visual Studio 2008? The complaint here is that the

LIBPATH environment variable was not found. The VS2008 vcvarsall.bat

batch file should have set LIBPATH for you.

Tim Roberts, timr@probo.com

Providenza & Boekelheide, Inc.

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Bruce Sherwood wrote:

Thanks to the very detailed instructions Andrea offered, I got quite a
ways in building Phoenix for 64-bit Windows. However, at the end of the
build I got the following error, despite which there is a folder named
"wx". Did I succeed or not?

Running command: build_wx
Command 'C:\Python32\python.exe -c "import distutils.msvc9compiler as
msvc; mc =
msvc.MSVCCompiler(); mc.initialize(); print(mc.cc)"' failed with exit
code 1.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Python32\lib\distutils\msvc9compiler.py", line 371, in initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
File "C:\Python32\lib\distutils\msvc9compiler.py", line 287, in
query_vcvarsal
l
raise ValueError(str(list(result.keys())))
ValueError: ['path', 'include', 'lib']
Finished command: build_wx (0.390s)

You'll want to look at the distutils.msvc9compiler module to see exactly what is going on. That first line above is basically using distutils to try and find the path to the compiler that is supposed to be used for building python extensions. If I remember correctly it is looking at the registry as well as the environment settings, and then will set the various environment variables that are needed from running that version of the compiler's vcvarsall batch file and looking at the environment produced.

If you unroll the python statements there then it may help you to better understand out what is going on and/or figure out what is not configured or being found correctly.

   import distutils.msvc9compiler as msvc
   mc = msvc.MSVCCompiler()
   mc.initialize()
   print(mc.cc)

From the traceback I see that it is failing in the call to query_vcvarsall from mc.initialize(). So look there.

Also, am I supposed to do some kind of build operation in the parallel
wxWidgets folder? Or is that folder there for the use of the Phoenix
build? The resulting wx folder is only about 10 MB, whereas the 32-bit
downloadable wx folders are about 35 MB, so I assume I haven't succeeded.

That is what the build_wx command is trying to do, build wxWidgets. It's the build_py command that will do the wxPython-Phoenix part of the build after wxWidgets is done.

···

--
Robin Dunn
Software Craftsman

Bruce Sherwood wrote:

Following Andrea's instructions, I put the following into a .bat file
and executed it. What's missing/wrong with respect to LIBPATH? I'm
guessing that LIBPATH means what LIB is set to, yes?

No. Why would you guess that? LIBPATH is different from LIB. You have
the source code. You can look at it. It tries to verify that there are
environment variables called PATH, LIB, INCLUDE, and LIBPATH. You don't
have LIBPATH.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

The reason I would guess that is that this whole area is exceedingly unfamiliar, and apparently Andrea didn’t need to set something called LIBPATH in order to build. I’ll look more closely. Thanks.

···

On Fri, Feb 15, 2013 at 10:31 AM, Tim Roberts timr@probo.com wrote:

Bruce Sherwood wrote:

Following Andrea’s instructions, I put the following into a .bat file

and executed it. What’s missing/wrong with respect to LIBPATH? I’m

guessing that LIBPATH means what LIB is set to, yes?

No. Why would you guess that? LIBPATH is different from LIB. You have

the source code. You can look at it. It tries to verify that there are

environment variables called PATH, LIB, INCLUDE, and LIBPATH. You don’t

have LIBPATH.

Tim Roberts, timr@probo.com

Providenza & Boekelheide, Inc.

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

I got a bit farther in attempting to build a 64-bit version of Phoenix, but I get a strange error shown at the end of this note.

The build.bat file I execute on Windows 7 with 64-bit Python 3.2, with Visual Studio 2008 (note that I gave a dummy entry for LIBPATH, which gets me past the first barrier I faced; I’ve reformatted the terminal output for readability):

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64;

C:\Python32;

C:\Program Files (x86)\Graphviz2.27\bin;

C:\Program Files (x86)\doxygen\bin;

C:\cygwin\bin;

C:\Python32\Scripts;C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\X64

set LIB=C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64;

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

set LIBPATH=;

set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include;

C:\Program Files\Microsoft SDKs\Windows\v7.0\Include;

C:\Python32\include

C:\Python32\python -u build.py 3.2 dox touch etg --nodoc sip build_wx build_py

In build.py, I put a print statement to display env in build.py just before the error exit shown below (I’ve reformatted the terminal output for readability):

Running command: build_wx

MSVC: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\cl.exe

env= {

‘path’: ';

C:\Program Files (x86)\Microsoft Visual Studio 9.0vcpackages;

C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;

C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64;

C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin;C:\Windows\Microsoft.NET\Framework64\v3.5;

C:\Windows\Microsoft.NET\Framework\v3.5;

C:\Windows\Microsoft.NET\Framework64\v2.0.50727;

C:\Windows\Microsoft.NET\Framework\v2.0.50727;!Path!’,

‘include’: ‘!ORIGINALINCLUDE!’,

‘lib’: ‘!ORIGINALLIB!’,

‘libpath’: ‘’

}

The error exit:

Traceback (most recent call last):

File “build.py”, line 1345, in

main(sys.argv[1:])

File “build.py”, line 157, in main

function(options, args)

File “build.py”, line 856, in build_wx

checkCompiler()

File “build.py”, line 557, in checkCompiler

os.environ[‘PATH’] = bytes(env[‘path’])

TypeError: string argument without an encoding

Finished command: build_wx (0.609s)

The question is, how can there be a string encoding issue with these simple ascii strings? Any suggestions on how to proceed? Thanks.

HI Bruce,

I got a bit farther in attempting to build a 64-bit version of Phoenix, but
I get a strange error shown at the end of this note.

The build.bat file I execute on Windows 7 with 64-bit Python 3.2, with
Visual Studio 2008 (note that I gave a dummy entry for LIBPATH, which gets
me past the first barrier I faced; I've reformatted the terminal output for
readability):

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64;
                C:\Python32;
                C:\Program Files (x86)\Graphviz2.27\bin;
                C:\Program Files (x86)\doxygen\bin;
                C:\cygwin\bin;
                C:\Python32\Scripts;C:\Program Files\Microsoft
SDKs\Windows\v7.0\Bin\X64
set LIB=C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64;
            C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64
set LIBPATH=;
set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include;
                     C:\Program Files\Microsoft SDKs\Windows\v7.0\Include;
                     C:\Python32\include
C:\Python32\python -u build.py 3.2 dox touch etg --nodoc sip build_wx
build_py

I don't remember ever setting anything called "LIBPATH" to compile
Phoenix, and actually on my Windows 7 box that variable doesn't even
exist... I compiled Phoenix for Python 2.7 and 3.2 with just the
attached file (rename the "txt" extension to "bat" to run it.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

build_phoenix.txt (600 Bytes)

···

On 16 February 2013 06:13, Bruce Sherwood wrote:

As you’ve seen, my .bat file is the same as yours except for invoking Python 3.2 (after all, I’m just copying your very helpful instructions). My guess is that there is a 2->3 issue with the build machinery, at least for 64-bit builds. You don’t set LIBPATH and it doesn’t stop the build; if I omit the LIBPATH (empty) setting, the build stops because it doesn’t find that reference. You get all the way through, I’m blocked by some strange error about an ordinary character string not having an encoding.

I’ll try building for 64-bit Windows Python 2.7, your situation, to see whether that works. I’ll do this only to try to understand my problem, which is my need to run on 64-bit Python 3.2 on Windows. For 64-bit Python 2.7 on Windows the classic wxPython is perfectly adequate, and on the Mac, the daily Phoenix build works with 64-bit Python 3.2.

Andrea, I tried the experiment of running exactly your .bat file, on 64-bit Python 2.7 instead of 3.2, and the build fails as shown below. Evidently there’s something wrong with my compiler environment, though I don’t have problems compiling the rather extensive VPython C++ code. I’ll try again on a different computer.

Running command: build_wx

MSVC: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\cl.exe

wxWidgets build options: [’–wxpython’, ‘–unicode’]

creating wx/msw/setup.h from setup0.h

setting build options…

Command ‘cl.exe’ failed with exit code 1.

ERROR: failed building wxWidgets

Traceback (most recent call last):

File “build.py”, line 928, in build_wx

wxbuild.main(wxscript, build_options)

File “M:\HP_Documents\Phoenix\wxWidgets\build/tools\build-wxwidgets.py”, line 422, in main

args.append(“COMPILER_VERSION=%s” % getVisCVersion())

File “M:\HP_Documents\Phoenix\wxWidgets\build/tools\build-wxwidgets.py”, line 62, in getVisCVersion

text = getoutput(“cl.exe”)

File “M:\HP_Documents\Phoenix\wxWidgets\build/tools\build-wxwidgets.py”, line 160, in getoutput

sys.exit(rval)

SystemExit: 1

Finished command: build_wx (0.515s)

Bruce Sherwood wrote:

I got a bit farther in attempting to build a 64-bit version of Phoenix,
but I get a strange error shown at the end of this note.

The error exit:

Traceback (most recent call last):
File "build.py", line 1345, in <module>
main(sys.argv[1:])
File "build.py", line 157, in main
function(options, args)
File "build.py", line 856, in build_wx
checkCompiler()
File "build.py", line 557, in checkCompiler
os.environ['PATH'] = bytes(env['path'])
TypeError: string argument without an encoding
Finished command: build_wx (0.609s)

The question is, how can there be a string encoding issue with these
simple ascii strings? Any suggestions on how to proceed? Thanks.

Because on Py3 string objects are actually unicode objects, and so converting to a bytes object requires an encoding. I'll get a fix in place soon for that build code.

In the meantime you can use Python 2.7 to run build.py, but still specify 3.2 on the command line so that will be used for building the python portions for the build. All the buildbot slaves are building this way too, using 2.7 to run the build but targeting whatever version is specified on the command line.

···

--
Robin Dunn
Software Craftsman

Interesting. I’ll try using Python 2.7 to build for 3.2, although the fact that I couldn’t even use Python 2.7 to build for Python 2.7, I’m not optimistic.

···

On Sat, Feb 16, 2013 at 3:06 PM, Robin Dunn robin@alldunn.com wrote:

Bruce Sherwood wrote:

I got a bit farther in attempting to build a 64-bit version of Phoenix,

but I get a strange error shown at the end of this note.

The error exit:

Traceback (most recent call last):

File “build.py”, line 1345, in

main(sys.argv[1:])

File “build.py”, line 157, in main

function(options, args)

File “build.py”, line 856, in build_wx

checkCompiler()

File “build.py”, line 557, in checkCompiler

os.environ[‘PATH’] = bytes(env[‘path’])

TypeError: string argument without an encoding

Finished command: build_wx (0.609s)

The question is, how can there be a string encoding issue with these

simple ascii strings? Any suggestions on how to proceed? Thanks.

Because on Py3 string objects are actually unicode objects, and so converting to a bytes object requires an encoding. I’ll get a fix in place soon for that build code.

In the meantime you can use Python 2.7 to run build.py, but still specify 3.2 on the command line so that will be used for building the python portions for the build. All the buildbot slaves are building this way too, using 2.7 to run the build but targeting whatever version is specified on the command line.

Robin Dunn

Software Craftsman

http://wxPython.org

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

I tried many schemes before finding one that nearly works, in the sense that instead of the build process terminating after a rather short time, the build process ran for several hours before failing. I built on a 64-bit Windows 7 machine that had never had any development software installed, and I installed Visual Studio 2008 and the Microsoft SDK.

As suggested by Andrea, I had to disable the waf machinery by making this change to the build_py function in build.py:

def build_py(options, args):

cmdTimer = CommandTimer(‘build_py’)

setup_py(options, args)

#waf_py(options, args)

Second, I had to include an (empty) specification of LIBPATH, something that somehow isn’t needed in Andrea’s situation.

Third, I incorporated Robin’s suggestion to execute with Python 2.7, even though I’m building for Python 3.2.

Here is the .bat file I used:

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64;C:\Python32;C:\Program Files (x86)\doxygen\bin;C:\cygwin\bin;C:\Python32\Scripts;C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\X64

set LIB=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64;C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\X64

set LIBPATH=;

set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include;C:\Program Files\Microsoft SDKs\Windows\v7.0\Include;C:\Python32\include

C:\Python27\python.exe -u build.py 3.2 clean dox touch etg --nodoc sip build_wx build_py

Alas, after building for hours, and just after processing _xml.pyd.manifest, the process failed with this message. I would of course appreciate any suggestions of what to try next. (For that matter, I would be delighted to be pointed to a 64-bit Windows Phoenix wxPython for Python 3.2 that someone has successfully built!)

LINK : fatal error LNK1181: cannot open input file ‘wxmsw29u_xml.lib’

error: command ‘“C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\link.exe”’ failed with exit status 1181

Command 'C:\Python27\python.exe -u ./setup.py build_ext --inplace BUILD_BASE=build ’ failed with exit code 1.

Finished command: setup_py (66m17.665s)

Finished command: build_py (66m17.665s)

Since it failed to find a library isn’t it worth trying to set a
LIBPATH that points to an actual directory?

···

On 18/02/13 05:08, Bruce Sherwood
wrote:

    I tried many schemes before finding one that nearly works, in

the sense that instead of the build process terminating after a
rather short time, the build process ran for several hours
before failing. I built on a 64-bit Windows 7 machine that had
never had any development software installed, and I installed
Visual Studio 2008 and the Microsoft SDK.

    As suggested by Andrea, I had to disable the waf machinery by

making this change to the build_py function in build.py:

def build_py(options, args):

cmdTimer = CommandTimer(‘build_py’)

setup_py(options, args)

#waf_py(options, args)

    Second, I had to include an (empty) specification of LIBPATH,

something that somehow isn’t needed in Andrea’s situation.

    Third, I incorporated Robin's suggestion to execute with

Python 2.7, even though I’m building for Python 3.2.

Here is the .bat file I used:

    set PATH=C:\Program Files (x86)\Microsoft Visual Studio

9.0\VC\bin\amd64;C:\Python32;C:\Program Files
(x86)\doxygen\bin;C:\cygwin\bin;C:\Python32\Scripts;C:\Program
Files\Microsoft SDKs\Windows\v7.0\Bin\X64

    set LIB=C:\Program Files (x86)\Microsoft Visual Studio

9.0\VC\lib\amd64;C:\Program Files\Microsoft
SDKs\Windows\v7.0\Lib\X64

set LIBPATH=;

    set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio

9.0\VC\include;C:\Program Files\Microsoft
SDKs\Windows\v7.0\Include;C:\Python32\include

    C:\Python27\python.exe -u build.py 3.2 clean dox touch etg

–nodoc sip build_wx build_py

    Alas, after building for hours, and just after processing

_xml.pyd.manifest, the process failed with this message. I would
of course appreciate any suggestions of what to try next. (For
that matter, I would be delighted to be pointed to a 64-bit
Windows Phoenix wxPython for Python 3.2 that someone has
successfully built!)

    LINK : fatal error LNK1181: cannot open input file

‘wxmsw29u_xml.lib’

    error: command '"C:\Program Files (x86)\Microsoft Visual

Studio 9.0\VC\bin\amd64\link.exe"’ failed with exit status 1181

    Command 'C:\Python27\python.exe -u ./setup.py build_ext

–inplace BUILD_BASE=build ’ failed with exit code 1.

Finished command: setup_py (66m17.665s)

Finished command: build_py (66m17.665s)

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to .
For more options, visit .


Steve Gadget Barnes

wxpython-users+unsubscribe@googlegroups.com
https://groups.google.com/groups/opt_out