w32 extension problem

Didrik_Pinte · May 13, 2009, 10:45pm

Hi,

I am trying to make Thuban using wxpython 2.8.

Under Debian (wxpython 2.8.7.1), everything runs fine. On windows
(wxpython 2.8.9.2), it seems that we have some compiler/linker issue
causing troubles when starting the app. A dailog box appears with the
following message.

0:27:54: Debug: ..\..\src\common\stdpbase.cpp(56): assert "traits"
failed in wxStandardPathsBase::Get(): create wxApp before calling this

If clicking on "Cancel", the application runs fine.

Googling a bit, I found that it could be related to the linking of
dll's. I have to admit that it goes out of my skills. So, if anybody
here can suggest me something to do, I would be pleased

Here are the macros, and libraries used during the compilation and
linking of the extension :

    wx_cs_params[CS_DEFS] = \
              [ ('WIN32', None), # Some of these are no longer
                ('__WIN32__', None), # necessary. Anybody know
                which?
                ('_WINDOWS', None),
                ('__WINDOWS__', None),
                ('WINVER', '0x0400'),
                ('__WIN95__', None),
                ('STRICT', None),

#('__WXMSW__', None),
('WXUSINGDLL', '1'),

                ('SWIG_GLOBAL', None),
                ('HAVE_CONFIG_H', None),
                ('WXP_USE_THREAD', '1'),
                ]

    wx_cs_params[CS_LIBS] = ['wxmsw28uh_core' , 'wxmsw28uh_stc',
    'wxbase28uh' ,\
                             'wxmsw28uh_html' , 'wxmsw28uh_richtext' ,
                             'wxmsw28uh_adv' , \
                             'wxmsw28uh_xrc' , 'wxmsw28uh_aui',
                             'wxmsw28uh_gl' , 'wxmsw28uh_gizmos' , \
                             'wxbase28uh_net' , 'wxbase28uh_xml']

When building the extension, we have the following output :

···

------------------------------------------------------------
running build_ext
building 'Lib.wxproj' extension
creating build
creating build\temp.win32-2.5
creating build\temp.win32-2.5\Release
creating build\temp.win32-2.5\Release\libraries
creating build\temp.win32-2.5\Release\libraries\thuban
C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\cl.exe /c /nologo
/Ox /MD /W3 /GX /DNDEBUG -DWIN32 -D__WIN32__ -D_WINDOWS -D__WINDOWS__
-DWINVER=0x0400 -
D__WIN95__ -DSTRICT -DWXUSINGDLL=1 -DSWIG_GLOBAL -DHAVE_CONFIG_H
-DWXP_USE_THREAD=1 /Ilibraries/shapelib /I..\proj-4.5.0\src
/Ilibraries/pyshapelib/ /I..\wxPyth
on-2.8.9.2\lib\vc_dll\mswuh /I..\wxPython-2.8.9.2\include
/IC:\Python25\include /IC:\Python25\PC /Tplibraries/thuban/wxproj.cpp
/Fobuild\temp.win32-2.5\Release\
libraries/thuban/wxproj.obj wxproj.cpp
creating build\lib.win32-2.5
creating build\lib.win32-2.5\Lib
C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\link.exe /DLL
/nologo /INCREMENTAL:NO /LIBPATH:..\proj-4.5.0\src
/LIBPATH:..\wxPython-2.8.9.2\lib\vc_dll
/LIBPATH:C:\Python25\libs /LIBPATH:C:\Python25\PCBuild proj_i.lib
wxmsw28uh_core.lib wxmsw28uh_stc.lib wxbase28uh.lib wxmsw28uh_html.lib
wxmsw28uh_richtext.lib
wxmsw28uh_adv.lib wxmsw28uh_xrc.lib wxmsw28uh_aui.lib wxmsw28uh_gl.lib
wxmsw28uh_gizmos.lib wxbase28uh_net.lib wxbase28uh_xml.lib
/EXPORT:initwxproj build\temp.
win32-2.5\Release\libraries/thuban/wxproj.obj
/OUT:build\lib.win32-2.5\Lib\wxproj.pyd
/IMPLIB:build\temp.win32-2.5\Release\libraries/thuban\wxproj.lib
Creating library
build\temp.win32-2.5\Release\libraries/thuban\wxproj.lib and object
build\temp.win32-2.5\Release\libraries/thuban\wxproj.exp
LINK : warning LNK4089: all references to 'msvcp71.dll' discarded by
/OPT:REF
LINK : warning LNK4089: all references to 'wxbase28uh_vc.dll' discarded
by /OPT:REF
------------------------------------------------------------

So it builds successfully but we have this message when starting the
application.

Thanks for any help.

Didrik
--
Didrik Pinte - Gérant/Manager

Dipole Consulting SPRL
E-mail : dpinte@dipole-consulting.com
Tel : +32 (0)10 779 005
Mobile : +32 (0)475 665 668
Fax : +32 (0)2 791 56 61
Web : http://www.dipole-consulting.com

TVA : BE.0895.560.517

Cody · May 13, 2009, 11:39pm

Hello,

···

On May 13, 2009, at 5:45 PM, lists@dipole-consulting.com wrote:

Hi,

I am trying to make Thuban using wxpython 2.8.

Under Debian (wxpython 2.8.7.1), everything runs fine. On windows
(wxpython 2.8.9.2), it seems that we have some compiler/linker issue
causing troubles when starting the app. A dailog box appears with the
following message.

0:27:54: Debug: ..\..\src\common\stdpbase.cpp(56): assert "traits"
failed in wxStandardPathsBase::Get(): create wxApp before calling this

I don't know what 'Thuban' is but this is a runtime error (not a compile/linker issue) of calling a function that requires the wxApp object to be created beforehand. (i.e its a bug in this program).

Cody

Didrik_Pinte · May 14, 2009, 12:01am

Even if it runs just perfectly on Linux ? The very same code causes no
error with a wx 2.8 on linux. This is win32 specific ...

Didrik

···

On Wed, 2009-05-13 at 18:39 -0500, Cody Precord wrote:

Hello,

On May 13, 2009, at 5:45 PM, lists@dipole-consulting.com wrote:

> Hi,
>
> I am trying to make Thuban using wxpython 2.8.
>
> Under Debian (wxpython 2.8.7.1), everything runs fine. On windows
> (wxpython 2.8.9.2), it seems that we have some compiler/linker issue
> causing troubles when starting the app. A dailog box appears with the
> following message.
>
> 0:27:54: Debug: ..\..\src\common\stdpbase.cpp(56): assert "traits"
> failed in wxStandardPathsBase::Get(): create wxApp before calling this
>
>

I don't know what 'Thuban' is but this is a runtime error (not a
compile/linker issue) of calling a function that requires the wxApp
object to be created beforehand. (i.e its a bug in this program).

Mauro_Cavalcanti · May 14, 2009, 12:12am

Thuban is an extensible, cross-platform, free, open source, Geographic
Information System desktop application written in Python with wxPython
as its GUI library. It can be find here: http://thuban.intevation.org/

Best regards,

···

2009/5/13 Cody Precord <codyprecord@gmail.com>:

I don't know what 'Thuban' is but this is a runtime error (not a
compile/linker issue) of calling a function that requires the wxApp object
to be created beforehand. (i.e its a bug in this program).

--
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: maurobio@gmail.com
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."

Cody · May 14, 2009, 12:57am

Hello,

···

On May 13, 2009, at 7:01 PM, Didrik Pinte wrote:

On Wed, 2009-05-13 at 18:39 -0500, Cody Precord wrote:

Hello,

On May 13, 2009, at 5:45 PM, lists@dipole-consulting.com wrote:

Hi,

I am trying to make Thuban using wxpython 2.8.

Under Debian (wxpython 2.8.7.1), everything runs fine. On windows
(wxpython 2.8.9.2), it seems that we have some compiler/linker issue
causing troubles when starting the app. A dailog box appears with the
following message.

0:27:54: Debug: ..\..\src\common\stdpbase.cpp(56): assert "traits"
failed in wxStandardPathsBase::Get(): create wxApp before calling this

I don't know what 'Thuban' is but this is a runtime error (not a
compile/linker issue) of calling a function that requires the wxApp
object to be created beforehand. (i.e its a bug in this program).

Even if it runs just perfectly on Linux ? The very same code causes no
error with a wx 2.8 on linux. This is win32 specific ...

On Linux wxStandardPaths is probably just checking environmental variables, on windows getting the correct paths may require a win32 api call that needs to have other things initialized in advance. (just a guess didn't actually check it out.)

Cody

Robin · May 14, 2009, 2:42am

Cody Precord wrote:

Hello,

Hello,

Hi,

I am trying to make Thuban using wxpython 2.8.

Under Debian (wxpython 2.8.7.1), everything runs fine. On windows
(wxpython 2.8.9.2), it seems that we have some compiler/linker issue
causing troubles when starting the app. A dailog box appears with the
following message.

0:27:54: Debug: ..\..\src\common\stdpbase.cpp(56): assert "traits"
failed in wxStandardPathsBase::Get(): create wxApp before calling this

I don't know what 'Thuban' is but this is a runtime error (not a
compile/linker issue) of calling a function that requires the wxApp
object to be created beforehand. (i.e its a bug in this program).

Even if it runs just perfectly on Linux ? The very same code causes no
error with a wx 2.8 on linux. This is win32 specific ...

On Linux wxStandardPaths is probably just checking environmental variables, on windows getting the correct paths may require a win32 api call that needs to have other things initialized in advance. (just a guess didn't actually check it out.)

Another possibility is that it's still an error on Linux, but it is silently ignored because wxWidgets was built with the runtime checks turned off.

···

On May 13, 2009, at 7:01 PM, Didrik Pinte wrote:

On Wed, 2009-05-13 at 18:39 -0500, Cody Precord wrote:

On May 13, 2009, at 5:45 PM, lists@dipole-consulting.com wrote:

--
Robin Dunn
Software Craftsman

Didrik_Pinte · May 14, 2009, 1:05pm

It seems more than only this wxStandardPaths error

If clicking on "Yes" on the dialog, the application quits
If clicking on "No" on the dialog, I got other errors like this but not
all related to wxStandardPaths. I can post them if needed.
If clicking on "Continue", everything runs smoothly.

What can I do to traceback the real problem ?

Thanks for your help guys,

Didrik

···

On Wed, 2009-05-13 at 19:42 -0700, Robin Dunn wrote:

>>> I don't know what 'Thuban' is but this is a runtime error (not a
>>> compile/linker issue) of calling a function that requires the wxApp
>>> object to be created beforehand. (i.e its a bug in this program).
>>
>> Even if it runs just perfectly on Linux ? The very same code causes no
>> error with a wx 2.8 on linux. This is win32 specific ...
>
>
> On Linux wxStandardPaths is probably just checking environmental
> variables, on windows getting the correct paths may require a win32 api
> call that needs to have other things initialized in advance. (just a
> guess didn't actually check it out.)

Another possibility is that it's still an error on Linux, but it is
silently ignored because wxWidgets was built with the runtime checks
turned off.

Cody · May 14, 2009, 1:43pm

Hello,

I don't know what 'Thuban' is but this is a runtime error (not a
compile/linker issue) of calling a function that requires the wxApp
object to be created beforehand. (i.e its a bug in this program).

Even if it runs just perfectly on Linux ? The very same code causes no
error with a wx 2.8 on linux. This is win32 specific ...

On Linux wxStandardPaths is probably just checking environmental
variables, on windows getting the correct paths may require a win32 api
call that needs to have other things initialized in advance. (just a
guess didn't actually check it out.)

Another possibility is that it's still an error on Linux, but it is
silently ignored because wxWidgets was built with the runtime checks
turned off.

It seems more than only this wxStandardPaths error

If clicking on "Yes" on the dialog, the application quits
If clicking on "No" on the dialog, I got other errors like this but not
all related to wxStandardPaths. I can post them if needed.
If clicking on "Continue", everything runs smoothly.

What can I do to traceback the real problem ?

Well its probably using StandardPaths to retrieve the location to keep/get its settings information. So after that fails it probably fails in all the places that are expecting that.

From the error shown before its because the wx.App object was not created yet. So that needs to be done before the call to StandardPaths. Can't say much more with out debugging the code of the that program.

Cody

···

On May 14, 2009, at 8:05 AM, Didrik Pinte wrote:

On Wed, 2009-05-13 at 19:42 -0700, Robin Dunn wrote:

Didrik_Pinte · May 14, 2009, 2:15pm

>
> What can I do to traceback the real problem ?

Well its probably using StandardPaths to retrieve the location to keep/
get its settings information. So after that fails it probably fails in
all the places that are expecting that.

Why does it work just fine when clicking on "Continue" ? It is just as
if they were not problem at all.

From the error shown before its because the wx.App object was not
created yet. So that needs to be done before the call to
StandardPaths. Can't say much more with out debugging the code of the
that program.

I will try to track down what wx thing could be called before creating
the app. They are lots of imports before creating the app, probably that
one of them is setting something on the wx side.

Is there a way to easily test or put the same debugging thing on Linux
to be sure it is not silently hiding the errors as Robin suggested ?

Didrik

···

On Thu, 2009-05-14 at 08:43 -0500, Cody Precord wrote:

Chris_Barker1 · May 14, 2009, 5:50pm

Didrik Pinte wrote:

I will try to track down what wx thing could be called before creating
the app. They are lots of imports before creating the app, probably that
one of them is setting something on the wx side.

What version of wx are you porting from?

A good while ago (2.4, 2.6?), wxPython initialized a lot more on import, then it was switched to not do the initialization until the wxApp was created. This means that start-up code written a long time ago needs to be refactored.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Didrik_Pinte · May 15, 2009, 1:54am

Hi Chris,

I guess that the ThubanApplication that extends wx.App has been written
somewhat near 2002/2003 ...

but it worked fine with the latest wx 2.6.3 and 2.6.4

Didrik

···

On Thu, 2009-05-14 at 10:50 -0700, Christopher Barker wrote:

Didrik Pinte wrote:
> I will try to track down what wx thing could be called before creating
> the app. They are lots of imports before creating the app, probably that
> one of them is setting something on the wx side.

What version of wx are you porting from?

A good while ago (2.4, 2.6?), wxPython initialized a lot more on import,
then it was switched to not do the initialization until the wxApp was
created. This means that start-up code written a long time ago needs to
be refactored.

-Chris

Didrik_Pinte · May 15, 2009, 3:52am

Thank you all guys for your quick and good
comments/reactions/suggestions.

I tracked down the problem a bit and found out that there was a call to
wx.Locale_AddCatalogLookupPrefix before creating the wx.App !

Thanks

Didrik

Chris_Barker1 · May 15, 2009, 6:51pm

Didrik Pinte wrote:

I tracked down the problem a bit and found out that there was a call to
wx.Locale_AddCatalogLookupPrefix before creating the wx.App !

I'm glad you figured it out -- is Thuban getting any attention lately? I've been wondering.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Didrik_Pinte · May 18, 2009, 8:32am

Hi Chris,

Not so much except mine (mainly for the HydroPlatform project
(http://www.hydroplatform.org). The mailing list is not very loud at the
moment but downloads are still ok.

Didrik

···

On Fri, 2009-05-15 at 11:51 -0700, Christopher Barker wrote:

Didrik Pinte wrote:
> I tracked down the problem a bit and found out that there was a call to
> wx.Locale_AddCatalogLookupPrefix before creating the wx.App !

I'm glad you figured it out -- is Thuban getting any attention lately?
I've been wondering.

Robin · May 19, 2009, 2:13am

Didrik Pinte wrote:

What can I do to traceback the real problem ?

Well its probably using StandardPaths to retrieve the location to keep/ get its settings information. So after that fails it probably fails in all the places that are expecting that.

Why does it work just fine when clicking on "Continue" ? It is just as
if they were not problem at all.

It may be that in this case it is warning you that it is wrong by design, but on your platform there is a reasonable default that is used instead when you dismiss the assert dialog.

From the error shown before its because the wx.App object was not created yet. So that needs to be done before the call to StandardPaths. Can't say much more with out debugging the code of the that program.

I will try to track down what wx thing could be called before creating
the app. They are lots of imports before creating the app, probably that
one of them is setting something on the wx side.

Is there a way to easily test or put the same debugging thing on Linux
to be sure it is not silently hiding the errors as Robin suggested ?

If you are on Debian or Ubuntu then you can try the "-dbg" version of the packages. Otherwise you'll probably have to build your own.

···

On Thu, 2009-05-14 at 08:43 -0500, Cody Precord wrote:

--
Robin Dunn
Software Craftsman