This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zvezdan
Recipients barry, brett.cannon, mark.dickinson, ronaldoussoren, zvezdan
Date 2009-09-22.21:01:58
SpamBayes Score 6.513738e-05
Marked as misclassified No
Message-id <1253653320.22.0.641905193113.issue6877@psf.upfronthosting.co.za>
In-reply-to
Content
Brett,

IMO, your backtrace only implies that readline module was built 
believing it has libedit (i.e., include files were system ones from 
/usr/include).

However, the following scenario is possible.  Some packaging tools 
choose to divide library packages into a runtime part and a development 
part.  If you had a copy of readline that was a runtime part only, it 
would have /usr/local/lib/* files but not /usr/local/include/* files 
(development part would have them).

Because of the way setup.py stashes /usr/local/lib first in the path, 
the build could have used system /usr/include/* file and linked to your 
local copy of readline library.

This is just a wild guess of course.

That's why I was interested in the output of otool command on your build 
of readline module.  That would tell us what it was linked to.
History
Date User Action Args
2009-09-22 21:02:00zvezdansetrecipients: + zvezdan, barry, brett.cannon, ronaldoussoren, mark.dickinson
2009-09-22 21:02:00zvezdansetmessageid: <1253653320.22.0.641905193113.issue6877@psf.upfronthosting.co.za>
2009-09-22 21:01:58zvezdanlinkissue6877 messages
2009-09-22 21:01:58zvezdancreate