There is probably a mismatch between settings in your build and the wxPython's version of wxWidgets that you are using. I noticed that in the include/wx/msw/setup.h file included in the devel tarball that wxUSE_DEBUG_CONTEXT and wxUSE_MEMORY_TRACING are set to 1. I believe that those should be set to zero, so try changing them and then recompile your code. The other possibility might be a mismatch in whether __WXDEBUG__ is set or not.
···
On 12/2/10 12:38 PM, wofeib wrote:
wxPython2.8-win32-devel for MSVC 9
wxPython2.8-win32-unicode-py26
wxPython-src
I downloaded all three packages.
I put everything from "wxPython2.8-win32-devel for MSVC 9" to folder
"wxPython-src-2.8.11.0".
My project is linked to the wxwidgets dll provided.
my project is using wxpython and wxwidgets at the same time. MSVS
2008.
Now my project is sucessfully compiled and linked. However it cann't
run.
(1) if I build my project in debug mode. It pops out:
" The application failed to initialize properly. "
(2) if I build my project in release mode. They say
"Mismatch between the program and library build versions detected.
The library used 2.8 (debug, unicode, visual c++, wx container,
compatible with 2.6), and your program used 2.8 (no debug, Unicode,
Visual c++, wx container, compatible with 2.6)
I double checked my project, it linked to wx**28uh**.lib. (Unicode and
Hybrid)
Now my project is sucessfully compiled and linked. However it cann't
run.
(1) if I build my project in debug mode. It pops out:
" The application failed to initialize properly. "
Trace through the initialization code with the debugger to see where that is coming from and why.
(2) if I build my project in release mode. They say
"Mismatch between the program and library build versions detected.
The library used 2.8 (debug, unicode, visual c++, wx container,
compatible with 2.6), and your program used 2.8 (no debug, Unicode,
Visual c++, wx container, compatible with 2.6)
I double checked my project, it linked to wx**28uh**.lib. (Unicode and
Hybrid)
Hybrid means that __WXDEBUG__ is defined (so asserts and etc. will be turned into Python exceptions) but it is a release mode build in every other way. The message tells me that your code is being compiled without __WXDEBUG__ being defined. Make sure that you don't define NDEBUG because that will turn off __WXDEBUG__ by default.
You are very helpful. Everytime you get the point. Yes, I defined
NDEBUG, take that away. My project is working in release mode.
However, in the debug mode, I still had the same problem:
" The application failed to initialize properly. "
I traced in and the error is:
no symbols loaded for ntdll.dll
do you know why? why "release" is ok but "debug" isn't?
That is probably not the real problem. That message just means that the debugger found no debug info for that DLL. You can install debug symbols for the system DLLs but I've never done it myself, and never really needed to.
···
On 12/9/10 2:25 PM, wofeib wrote:
Robin,
You are very helpful. Everytime you get the point. Yes, I defined
NDEBUG, take that away. My project is working in release mode.
However, in the debug mode, I still had the same problem:
" The application failed to initialize properly."
I traced in and the error is:
no symbols loaded for ntdll.dll
do you know why? why "release" is ok but "debug" isn't?
Subject: [wxPython-users] Re: window development problem
Robin,
You are very helpful. Everytime you get the point. Yes, I defined
NDEBUG, take that away. My project is working in release mode.
However, in the debug mode, I still had the same problem:
" The application failed to initialize properly. "
I traced in and the error is:
no symbols loaded for ntdll.dll
do you know why? why “release” is ok but “debug” isn’t?
Thank you.
Your debugger is moaning because that dll has not been built with debug enabled, if you need to get rid of the warning you will need to get or build the debug version of the library, probably called ntdll_d.dll, and in your debug build link to that instead of ntdll.dll, however unless your problem lies somewhere inside the dll or in the way you are calling functions from it you should not need to debug inside the dll so it shouldn’t be a problem.
I used "depends" and "start profile", the error is below:
GetProcAddress(0x773D0000 [COMCTL32.DLL], "RegisterClassNameW") called
from "USER32.DLL" at address 0x7E44A6B0 and returned NULL. Error: The
specified procedure could not be found (127).
DllMain(0x78520000, DLL_PROCESS_ATTACH, 0x0590FD30) in "MSVCR90.DLL"
returned 0 (0x0).
Second chance exception 0xC0000142 (DLL Initialization Failed)
occurred in "NTDLL.DLL" at address 0x7C9666C6.
Exited "SEC_MUL_PROC_WX_EXEC.EXE" (process 0x658) with code
-1073741502 (0xC0000142).
Entrypoint reached. All implicit modules have been loaded.
On the contrary, the "profile" for the "release exe" doesn't have this
line, means release exe doesn't require "RegisterClassNameW" proc.
I used "depends" and "start profile", the error is below:
GetProcAddress(0x773D0000 [COMCTL32.DLL], "RegisterClassNameW") called
from "USER32.DLL" at address 0x7E44A6B0 and returned NULL. Error: The
specified procedure could not be found (127).
DllMain(0x78520000, DLL_PROCESS_ATTACH, 0x0590FD30) in "MSVCR90.DLL"
returned 0 (0x0).
Second chance exception 0xC0000142 (DLL Initialization Failed)
occurred in "NTDLL.DLL" at address 0x7C9666C6.
Exited "SEC_MUL_PROC_WX_EXEC.EXE" (process 0x658) with code
-1073741502 (0xC0000142).
Entrypoint reached. All implicit modules have been loaded.
On the contrary, the "profile" for the "release exe" doesn't have this
line, means release exe doesn't require "RegisterClassNameW" proc.
I would guess that it still does use it but for some reason it's being found in that case.
But how to fix "debug exe"?
I'm not sure how much more help I can be beyond making guesses, as this is starting to get past my experiences. One more guess: Is there any part of your application (the application code or additional libraries that you use) that is compiled without the /MDd flag in the debug build?
I'm not sure how much more help I can be beyond making guesses, as this
is starting to get past my experiences. One more guess: Is there any
part of your application (the application code or additional libraries
that you use) that is compiled without the /MDd flag in the debug build?
as I remember, I linked the python.lib for both debug and release.
I mean, I didn't link python_d.lib because it didn't provide
python_d.lib.
Robin, could you please explain me more why you guess it's because
something is compiled without /MDd flag based on
error here:
"GetProcAddress(0x773D0000 [COMCTL32.DLL], "RegisterClassNameW")
called
from "USER32.DLL" at address 0x7E44A6B0 and returned NULL. Error:
The
specified procedure could not be found (127).
I'm not sure how much more help I can be beyond making guesses, as this
is starting to get past my experiences. One more guess: Is there any
part of your application (the application code or additional libraries
that you use) that is compiled without the /MDd flag in the debug build?
as I remember, I linked the python.lib for both debug and release.
I mean, I didn't link python_d.lib because it didn't provide
python_d.lib.
In that case you need to make sure that **nothing** is being built with /MDd otherwise you'll get runtime library conflicts or worse. That includes Python, wxPython, wxWidgets, your application, and any other libraries you are linking together. OTOH, it really isn't hard to make your own debug build of Python and then you won't have to fight with everything else that you are linking that wants to use /MDd for the debug build.
Robin, could you please explain me more why you guess it's because
something is compiled without /MDd flag based on
error here:
"GetProcAddress(0x773D0000 [COMCTL32.DLL], "RegisterClassNameW")
called
from "USER32.DLL" at address 0x7E44A6B0 and returned NULL. Error:
The
specified procedure could not be found (127).
I think it was just a hunch based on another part of the text in that message.
I found wx**28un**.lib linked to MSVCR90.dll and MSVCP90.dll.
OTOH, in the debug mode, the project needs to link with MSVCR90D.dll
and MSVCP90D.dll.
I'm wondering if they are causing library conflicts? MSVCR90.dll vs.
MSVCR90D.dll?
Thank you.
···
In that case you need to make sure that **nothing** is being built with
/MDd otherwise you'll get runtime library conflicts or worse. That
includes Python, wxPython, wxWidgets, your application, and any other
libraries you are linking together. OTOH, it really isn't hard to make
your own debug build of Python and then you won't have to fight with
everything else that you are linking that wants to use /MDd for the
debug build.
That is the main difference between using /MD and /MDd and is why all components of your application need to use the same setting in the same build type.
···
On 12/16/10 6:26 AM, wofeib wrote:
Hello,
I found wx**28un**.lib linked to MSVCR90.dll and MSVCP90.dll.
OTOH, in the debug mode, the project needs to link with MSVCR90D.dll
and MSVCP90D.dll.
I'm wondering if they are causing library conflicts? MSVCR90.dll vs.
MSVCR90D.dll?
I know the difference between /MD and /MDd. All components of my
application using /MDd.
My question is: when I use "dependency walker" to view the generated
exe file, exe file linked to WXBASE28UH_VC.DLL, MSVCP90D.dll,
MSVCR90D.dll, however WXBASE28UH_VC.DLL linked to MSVCP90.dll and
MSVCR90.dll. Therefore, there are conflicts between MSVCP90D.dll vs
MSVCP90.dll, MSVCR90D.dll vs MSVCR90.dll?
I'm wondering how to fix it to make WXBASE28UH_VC.DLL linked to
MSVCP90D.dll and MSVCR90D.dll?
I tried to set "ingnore specific lib: MSVCRT;MSVCP90;MSVCR90" in MSVC
and it doesn't help.
The "UH" in the DLL names mean that they are a Unicode "Hybrid" build, which means they were built with /MD and with __WXDEBUG__ defined. In other words, a release build with a bit of debug functionality tossed in.
If you are making a debug build of your app (and any other libraries that you use) then you need to do a debug build of wxWidgets and wxPython to go with it. A debug build will have "UD" in the DLL names instead of "UH".
···
On 12/16/10 9:52 AM, wofeib wrote:
I know the difference between /MD and /MDd. All components of my
application using /MDd.
My question is: when I use "dependency walker" to view the generated
exe file, exe file linked to WXBASE28UH_VC.DLL, MSVCP90D.dll,
MSVCR90D.dll, however WXBASE28UH_VC.DLL linked to MSVCP90.dll and
MSVCR90.dll. Therefore, there are conflicts between MSVCP90D.dll vs
MSVCP90.dll, MSVCR90D.dll vs MSVCR90.dll?
I'm wondering how to fix it to make WXBASE28UH_VC.DLL linked to
MSVCP90D.dll and MSVCR90D.dll?
I tried to set "ingnore specific lib: MSVCRT;MSVCP90;MSVCR90" in MSVC
and it doesn't help.
The "UH" in the DLL names mean that they are a Unicode "Hybrid" build,
which means they were built with /MD and with __WXDEBUG__ defined. In
other words, a release build with a bit of debug functionality tossed in.
If you are making a debug build of your app (and any other libraries
that you use) then you need to do a debug build of wxWidgets and
wxPython to go with it. A debug build will have "UD" in the DLL names
instead of "UH".
I get your point. But that makes application hard to use.
The dll I'm using is downloaded from "wxPython2.8-win32-devel for MSVC
9".
wxpython is installed by "wxPython2.8-win32-unicode-py26"
my project uses both wxpython and wxwidgets.
As you said, when I switch the project build option debug/release,
it's required to link to debug/release of wxwidgets/wxpython.
It looks like I must install/uninstall wxpython everytime I make a
build switch in MSVS. That's not very good.
I'm wondering if there is a general dll for wxpython/wxwidgets can be
linked to both debug and release.
The "UH" in the DLL names mean that they are a Unicode "Hybrid" build,
which means they were built with /MD and with __WXDEBUG__ defined. In
other words, a release build with a bit of debug functionality tossed in.
If you are making a debug build of your app (and any other libraries
that you use) then you need to do a debug build of wxWidgets and
wxPython to go with it. A debug build will have "UD" in the DLL names
instead of "UH".
I get your point. But that makes application hard to use.
The dll I'm using is downloaded from "wxPython2.8-win32-devel for MSVC
9".
wxpython is installed by "wxPython2.8-win32-unicode-py26"
my project uses both wxpython and wxwidgets.
As you said, when I switch the project build option debug/release,
it's required to link to debug/release of wxwidgets/wxpython.
It looks like I must install/uninstall wxpython everytime I make a
build switch in MSVS. That's not very good.
No, the debug files should be able to coexist side-by-side with the release files, because the wxWidgets debug DLLs will have the "ud" in the names, and the wxPython extension modules will have "_d" in the name like the debug Python exe, DLL and other extension modules do.
On the other hand, it wouldn't be hard to just use the debug wxWidgets and wxPython files from the build directory instead of the install dir, you just need to set PATH and PYTHONPATH accordingly when running the debug version of your application.
I'm wondering if there is a general dll for wxpython/wxwidgets can be
linked to both debug and release.
Yes, but it won't be very easy. There can only be one copy of wxWidgets in the same process, and if you link it statically to your application then that is one copy and then the DLL that wxPython uses would be another copy. To get around that you would also have to statically link all of the wxPython extension modules to your application as well. This should possible to do since Python was designed since 1.x to do it back in the days before dynamic library implementations converged and stabilized. TBH I haven't done it myself since then so I don't remember everything about how it is done. What I do remember is that there is a snippet of code you need to include in your application that has a static array with static module names and a reference to the init function in every module that is to be linked statically. Then you pass that array to the function you call to initialize the Python interpreter.
···
On 12/24/10 7:34 AM, wofeib wrote:
Hi, Robin,
Follow previous discussion, can we build wxpython and wxwidgets using
static lib instead of dll?
For example, my application is using ffmpeg, I just linked to the libs
and my application works in both debug and release build.
