[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] No module named wx

From: John Clark
Subject: Re: [Discuss-gnuradio] No module named wx
Date: Fri, 15 Apr 2005 10:39:59 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050111

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?



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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]