Error importing wxPython

wxPython Users
1

NOTE: I sent this message off last night, but it doesn't
seem to have gotten through so here it is again. Appologies
if the list gets more than one copy.

I just got wxGTK/wxPython compiled, and tried to test it
out, getting the following error message:

···

------------------------------------------------------

from wxPython import wx

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wx.py", line
+2, in ?
    import wxc
ImportError: ld.so.1: python: fatal: relocation error: file
+/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wxc.so: symbol
+__eprintf: referenced symbol not found

------------------------------------------------------

OS: Solaris 8
Python: 2.3
wxPython: 2.4.1.2
wxGTK: (built-in)

Standard build instructions, though without --enable-rpath
in order to get wxPython to compile. (As per Robin Dunn)

Any help?

--David

2

David Morris wrote:

from wxPython import wx

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wx.py", line
+2, in ?
    import wxc
ImportError: ld.so.1: python: fatal: relocation error: file
+/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wxc.so: symbol
+__eprintf: referenced symbol not found

------------------------------------------------------

OS: Solaris 8
Python: 2.3
wxPython: 2.4.1.2
wxGTK: (built-in)

Standard build instructions, though without --enable-rpath
in order to get wxPython to compile. (As per Robin Dunn)

Probably an additional library needs to be added to the link step in the build so it will get loaded at runtime. Can you figure out what lib _eprintf is located in?

BTW, once you get all this figured out it would be great to have a patch for the build instructions that describes the problems and workarounds for Solaris.

···

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

3

Sorry for mangling the order, makes the mail easier to read.

BTW, once you get all this figured out it would be great to have a patch
for the build instructions that describes the problems and workarounds
for Solaris.

I'd be glad to provide a patch of the instructions (and any
other modifications I make) along the way.

David Morris wrote:
>
>>>>from wxPython import wx
>
>Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wx.py",
> line
>+2, in ?
> import wxc
>ImportError: ld.so.1: python: fatal: relocation error: file
>+/usr/local/python/2.3/lib/python2.3/site-packages/wxPython/wxc.so: symbol
>+__eprintf: referenced symbol not found
>
>------------------------------------------------------
>
>OS: Solaris 8
>Python: 2.3
>wxPython: 2.4.1.2
>wxGTK: (built-in)
>
>Standard build instructions, though without --enable-rpath
>in order to get wxPython to compile. (As per Robin Dunn)

Probably an additional library needs to be added to the link step in the
build so it will get loaded at runtime. Can you figure out what lib
__eprintf is located in?

More info, uncertain of how to implement the fix:

A bit of digging found that this is caused by solaris ld
being used (/usr/ccs/bin/ld) instead of gcc ld. solaris ld
does not link in libgcc.a (which is vital to gcc apps!).
The fix is to add this to the link step of all shared
libraries:

-L<path-to-gcc-lib> -lgcc

On my system, this is:

-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -lgcc

As the build does use 'c++ -shared' (I checked the actual command it
used), this means the wrong ld is being found/used on the
system. I'm still working on if there is a way to convince
it to find the "correct" version of ld.

In the meantime, is there an easy way to add the above
workaround to the build script?

--David

···

On Thu, Sep 11, 2003 at 11:39:30AM -0700, Robin Dunn wrote:

4

David Morris wrote:

More info, uncertain of how to implement the fix:

A bit of digging found that this is caused by solaris ld
being used (/usr/ccs/bin/ld) instead of gcc ld. solaris ld
does not link in libgcc.a (which is vital to gcc apps!).

Ah, I should have remembered. I've run into this before.

The fix is to add this to the link step of all shared
libraries:

-L<path-to-gcc-lib> -lgcc

On my system, this is:

-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -lgcc

As the build does use 'c++ -shared' (I checked the actual command it
used), this means the wrong ld is being found/used on the
system. I'm still working on if there is a way to convince
it to find the "correct" version of ld.

In the meantime, is there an easy way to add the above
workaround to the build script?

Yep. Around line 480 of setup.py add the 'gcc' to the libs list and the <path-to-gcc-lib> to the libdirs list. (Although you may want to try it without adding the libdir as it may already be on the path that is searched.)

If you can figure out a way to detect Solaris from setup.py then we can make that a permanent part of setup.py.

···

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

5

David Morris wrote:
>The fix is to add this to the link step of all shared
>libraries:
>
>-L<path-to-gcc-lib> -lgcc
>
>On my system, this is:
>
>-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -lgcc
>
>As the build does use 'c++ -shared' (I checked the actual command it
>used), this means the wrong ld is being found/used on the
>system. I'm still working on if there is a way to convince
>it to find the "correct" version of ld.
>
>In the meantime, is there an easy way to add the above
>workaround to the build script?

Yep. Around line 480 of setup.py add the 'gcc' to the libs list and the
<path-to-gcc-lib> to the libdirs list. (Although you may want to try it
without adding the libdir as it may already be on the path that is
searched.)

Thanks, I added in the relevant code, and am running the
build now....

If you can figure out a way to detect Solaris from setup.py then we can
make that a permanent part of setup.py.

Simplicity itself, just FYI the key is to use os.uname()
(available on all unix systems). The first item in the
array is the OS, in this case SunOS.

If the change works (takes forever to compile), I'll send
off a patch of what I changed.

--David

···

On Thu, Sep 11, 2003 at 12:53:45PM -0700, Robin Dunn wrote:

6

See the attached patch file.

YMMV

This patch might not be needed on all solaris
systems....it is quite possible neither is needed if the
solaris compiler is used for compilation instead of the GNU
compiler (gcc). Certainly the patch to setup.py is needed
only if gcc is being used.

You might include the README.1st.txt patch (or something
similar) always, but distribute the setup.py patch
sepperately with a note to include it if needed....either
than, or work to make it more generic.

Good luck, and thanks for the help solving the problems!

--David

patchfile (2.23 KB)

···

On Thu, Sep 11, 2003 at 12:53:45PM -0700, Robin Dunn wrote:

If you can figure out a way to detect Solaris from setup.py then we can
make that a permanent part of setup.py.