On May 09, 2012, at 02:17 AM, Matthias Klose wrote: >IMO, the correct fix would be not to hard-code the system include and library >directories, but get them from gcc directly (if CC is gcc), and not relying on >dpkg-architecture. > >$ gcc -v -E - </dev/null >[...] >#include <...> search starts here: > /usr/lib/gcc/x86_64-linux-gnu/4.6/include > /usr/local/include > /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed > /usr/include/x86_64-linux-gnu > /usr/include >End of search list. >[...] >LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/ +1 This would make a good fix for Python 3.3. Matthias, perhaps you can work up a patch for that? -Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4