Re: [Discuss-gnuradio] No module named wx

[John Clark]

Angilberto Muniz Sb wrote:

> Similar situation down here in Brazil, but
> after adding the softlink it complains with
> "file not found..." or something similar...
>
> Any tips on where to put some break code to help debug
> the issue?
>
> Rgrds,
>
> Angilberto.

While I don't have any further specific information, I have pursued a
'problem' on some of the 'upstream' packages from GNURadio. While
this package may or may not be directly used by GNURadio, or
the wxPython package, I was lead up stream by the site were the
wxPython package is located.

I was compiling PyOpenGL, and ran across what is to me an astonishing
'feature' of the modern GCC preprocessor.

First note, I did not build up the linux system I'm currently working 
on. The
system was build by someone else, based on the 'Gentoo' distribution. I 
don't
know why this was done, but I tended to leave the set up as is.

On to GCC. Apparently in the intervening 26 years that I've been C 
programming
someone has decided that if a 'system include' appears as an argument to 
an explicit
'-I<path>', that it should be eliminated, so as to prevent someone from 
overriding the
compiled 'search order'. (According to 'man gcc'...)

Well, I thought that's exactly why the '-I' was created, to override the 
'default search order'.

Anyway, in compiling PyOpenGL, I placed an explicit 
'-I/usr/local/include' in my configuration
file, thinking that because I had placed a different version of 
'OpenGL', actually 'Mesa' there
the compiler and all the make files would search '/usr/local/include' 
FIRST before anything else
and move on if the include file was not found.

As it so happens the system that I'm working on had an older/different 
version of OpenGL installed
and has 'GL/*.h' in the 'standard places'. Hence, when the fancy 
compiler feature eliminated my
explicit search path, the older/different include files where brought in 
and eventually caused a
break in a typedef that needed to exist.

What I did to 'correct' this was to create a new directory, 
'/usr/local/include_n', copy the heirarchy
from /usr/local/include to the new place, fix the configure file to 
point to the new directory,
and lo and behold, PyOpenGL compiles and installs without further trouble.

What I'm going to do is recompile my standard 'compiler' setup to 
eliminate all but 'real' system
includes in the search list, so that in the future at least this problem 
will not occur again.

The object lesson here is that these 'packages' have incredibly 
sensitive setup conditions which
are not 'obvious' in the least. Further, the 'configure' program does 
not seem to really catch
a lot of this.

John