[wxPython] RE: [SciPy-dev] Announce: First installable version of Chaco plotting toolkit is now available

What versions of other stuff are required? I'm having trouble

    > building wxPython and wxGTK on both Linux (using gcc/g++) and
    > Solaris (using suncc/sunc++).

    > It should work with 2.3.2 and 2.3.3.1 (current). I think there
    > are RPMs available for Linux at www.wxpython.org.

I'll hold off on Solaris for now, since that environment is a bit different.
On Linux, I started with wxPythonSrc-2.3.3.1 and followed the directions at
http://www.wxpython.org/README.1st.txt to build it. Specifically, I did
this:

    mkdir build
    cd build
    export WXPREF=/usr/local
    ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \
        --with-opengl --enable-optimise --enable-debug_flag \
        --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \
        --with-zlib=builtin

[There is a typo in the README.1st.txt file - the --with-libjpeg=builtin arg
is missing a dash.]

    make
    cd ../locale
    make allmo
    cd ../build
    make install
    cd ../wxPython
    python setup.py \
           IN_CVS_TREE=1 WX_CONFIG=$WXPREF/bin/wx-config \
           build install

I then went to the wxPython/demo directory and executed

    python demo.py

which yielded:

    Traceback (most recent call last):
      File "demo.py", line 3, in ?
        import Main
      File "Main.py", line 15, in ?
        from wxPython.wx import *
      File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ?
        import wxc
    ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: __ti7wxEvent

I poked around for "__ti7wxEvent". All I found were a couple undefined
references:

    for f in `find . -name '*.so'` ; do
        n=`nm -p $f | egrep __ti7wxEvent | wc -l`
        if [ $n -gt 0 ] ; then
            echo $f
            nm -p $f | egrep __ti7wxEvent
        fi
    done

    ./python2.3/site-packages/wxPython/wxc.so
             U __ti7wxEvent
    ./python2.3/site-packages/wxPython/gizmosc.so
             U __ti7wxEvent

I then went back to the wxPython build tree and scanned the .o files for
that symbol using a for loop similar to the above. This yielded:

    ./wxPython/build/temp.linux-i686-2.3/helpers.o
             U __ti7wxEvent
    ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o
             U __ti7wxEvent

According to c++filt, that symbol corresponds to

    wxEvent type_info node

My environment is Mandrake 8.1, Python from CVS (2.3a0-ish) built with gcc.

···

--
Skip Montanaro - skip@pobox.com
The need for gutters to be cleaned is directly proportional to how hard it
happens to be raining at the moment.

Skip Montanaro wrote:

I'll hold off on Solaris for now, since that environment is a bit different.
On Linux, I started with wxPythonSrc-2.3.3.1 and followed the directions at
http://www.wxpython.org/README.1st.txt to build it. Specifically, I did
this:

    mkdir build
    cd build
    export WXPREF=/usr/local
    ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \
        --with-opengl --enable-optimise --enable-debug_flag \
        --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \
        --with-zlib=builtin

If you're going to install wxWindows into /usr/local then there's no real reason to follow the directions for the private wx, but it should still work like this...

[There is a typo in the README.1st.txt file - the --with-libjpeg=builtin arg
is missing a dash.]

Thanks. I'll get this fixed.

I then went to the wxPython/demo directory and executed

    python demo.py

which yielded:

    Traceback (most recent call last):
      File "demo.py", line 3, in ?
        import Main
      File "Main.py", line 15, in ?
        from wxPython.wx import *
      File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ?
        import wxc
    ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: __ti7wxEvent

I poked around for "__ti7wxEvent". All I found were a couple undefined
references:

[...]

    ./wxPython/build/temp.linux-i686-2.3/helpers.o
             U __ti7wxEvent
    ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o
             U __ti7wxEvent

According to c++filt, that symbol corresponds to

    wxEvent type_info node

My environment is Mandrake 8.1, Python from CVS (2.3a0-ish) built with gcc.

I've just tried exactly what you did above on my Mandrake 8.2 system with Python 2.2 and it works fine.

One possibility -- since the wxPython build gets its compiler flags and etc. from Python's build via distutils -- is that there is some flag conflicting with wxGTK's build that has changed with Python 2.3. I'd be interested in seeing a copy of a compile commandline for one of the sources from the wxGTK build and another one from the wxPython build.

Another possibility is that it may be fixed simply by disabling rtti and/or exceptions in the wxGTK build. You can try adding the following flags and then rebuilding all of wxGTK and wxPython:

  --enable-no_rtti
  --enable-no_exceptions

RTTI and exceptions are not needed by wxPython so I guess I should probably add them to the "Private wxGTK" instructions anyway as there should be a bit of a performance boost...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

export WXPREF=/usr/local

    > ../configure --with-gtk --prefix=$WXPREF --enable-rpath=$WXPREF/lib \
    > --with-opengl --enable-optimise --enable-debug_flag \
    > --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin \
    > --with-zlib=builtin

    > If you're going to install wxWindows into /usr/local then there's
    > no real reason to follow the directions for the private wx, but
    > it should still work like this...

That's what I figured, but I also figured it was marginally better to be
pedantic in case WXPREF was used somewhere other than via the command line.

    > I poked around for "__ti7wxEvent". All I found were a couple undefined
    > references:
    > ./wxPython/build/temp.linux-i686-2.3/helpers.o
    > U __ti7wxEvent
    > ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o
    > U __ti7wxEvent

    > I've just tried exactly what you did above on my Mandrake 8.2
    > system with Python 2.2 and it works fine.

What file defines wxEvent? You must surely have a .o file which defines it
as an exportable symbol.

    > One possibility -- since the wxPython build gets its compiler
    > flags and etc. from Python's build via distutils -- is that there
    > is some flag conflicting with wxGTK's build that has changed with
    > Python 2.3. I'd be interested in seeing a copy of a compile
    > commandline for one of the sources from the wxGTK build and
    > another one from the wxPython build.

An example from (wxPython's internal) wxGTK with the no_rtti and
no_exceptions flags set:

    c++ -c -I./lib/wx/include/gtkd-2.3 -I../include -I../src/zlib \
    -I../src/png -I../src/jpeg -I../src/tiff -I/usr/include/gtk-1.2 \
    -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT \
    -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES \
    -D__WXGTK__ -D__WXDEBUG__ -fno-rtti -fno-exceptions -O2 -MMD -pthread \
    -Wall -fPIC -o brush.o ../src/gtk/brush.cpp

Here's one from wxPython:

    gcc -DNDEBUG -O3 -fPIC -DSWIG_GLOBAL -DHAVE_CONFIG_H -DWXP_USE_THREAD=1 \
    -Isrc -I/usr/local/include/python2.3 -c contrib/dllwidget/dllwidget.cpp \
    -o build/temp.linux-i686-2.3/dllwidget.o \
    -I/usr/local/lib/wx/include/gtkd-2.3 -D__WXDEBUG__ -D__WXGTK__ \
    -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -fno-rtti -fno-exceptions \
    -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include \
    -I/usr/X11R6/include -UNDEBUG

    > Another possibility is that it may be fixed simply by disabling
    > rtti and/or exceptions in the wxGTK build. You can try adding
    > the following flags and then rebuilding all of wxGTK and
    > wxPython:

    > --enable-no_rtti
    > --enable-no_exceptions

Just tried that. Running wxPython/demo/demo.py now yields:

    Traceback (most recent call last):
      File "demo.py", line 3, in ?
        import Main
      File "Main.py", line 15, in ?
        from wxPython.wx import *
      File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ?
        import wxc
    ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so:
    undefined symbol: Eof__C13wxInputStream

which c++filt reports as

    wxInputStream::Eof(void) const

The original __ti7wxEvent symbol is no longer to be found anywhere (defined
or referenced). Eof__C13wxInputStream is referenced from
./wxPython/build/temp.linux-i686-2.3/helpers.o.

Ah, wait a minute. I see a likely candidate for the screwup:

    % type c++
    c++ is /usr/local/bin/c++
    % c++ --version
    3.0.4
    % type gcc
    gcc is /usr/bin/gcc
    % gcc --version
    2.96

Does mix-n-match across GCC versions strike you as a plausible reason for
the errors? I am rebuilding while I await your reply...

Skip

Skip Montanaro wrote:

    > I poked around for "__ti7wxEvent". All I found were a couple undefined
    > references:
    > ./wxPython/build/temp.linux-i686-2.3/helpers.o
    > U __ti7wxEvent
    > ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o
    > U __ti7wxEvent

    > I've just tried exactly what you did above on my Mandrake 8.2
    > system with Python 2.2 and it works fine.

What file defines wxEvent? You must surely have a .o file which defines it
as an exportable symbol.

It should be in wxGTK in src/common/event.cpp (build/event.o).

    > One possibility -- since the wxPython build gets its compiler
    > flags and etc. from Python's build via distutils -- is that there
    > is some flag conflicting with wxGTK's build that has changed with
    > Python 2.3. I'd be interested in seeing a copy of a compile
    > commandline for one of the sources from the wxGTK build and
    > another one from the wxPython build.

An example from (wxPython's internal) wxGTK with the no_rtti and
no_exceptions flags set:

[...]

These look okay.

    > Another possibility is that it may be fixed simply by disabling
    > rtti and/or exceptions in the wxGTK build. You can try adding
    > the following flags and then rebuilding all of wxGTK and
    > wxPython:

    > --enable-no_rtti
    > --enable-no_exceptions

Just tried that. Running wxPython/demo/demo.py now yields:

    Traceback (most recent call last):
      File "demo.py", line 3, in ?
        import Main
      File "Main.py", line 15, in ?
        from wxPython.wx import *
      File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ?
        import wxc
    ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so:
    undefined symbol: Eof__C13wxInputStream

which c++filt reports as

    wxInputStream::Eof(void) const

The original __ti7wxEvent symbol is no longer to be found anywhere (defined
or referenced).

Right, it shouldn't be since you built without RTTI.

Eof__C13wxInputStream is referenced from
./wxPython/build/temp.linux-i686-2.3/helpers.o.

I don't see anyway that a whole method could get lost...

Ah, wait a minute. I see a likely candidate for the screwup:

    % type c++
    c++ is /usr/local/bin/c++
    % c++ --version
    3.0.4
    % type gcc
    gcc is /usr/bin/gcc
    % gcc --version
    2.96

Does mix-n-match across GCC versions strike you as a plausible reason for
the errors?

...except for this. It's likely that the C++ symbol names are getting mangled differently by the different compiler versions and the one symbol reported by the import exception is just the first one found.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Does mix-n-match across GCC versions strike you as a plausible reason

    >> for the errors?

    > ...except for this. It's likely that the C++ symbol names are
    > getting mangled differently by the different compiler versions
    > and the one symbol reported by the import exception is just the
    > first one found.

Thanks, that did the trick. Now to wage battle with the dragon named
Solaris...

Skip