On 4/14/19 9:07 PM, Adam Weinberger wrote: > On Sun, Apr 14, 2019 at 6:26 PM George Mitchell <[email protected]> > wrote: >> >> But I forgot that, and ended up with both /lib/libreadline.so.8 >> AND /usr/local/lib/libreadline.so.8 on my machine, leading to woe >> when compiling the latest lang/python36. Unfortunately, the base >> version readline was quite a bit older than the one from ports. >> >> Nevertheless, the ports version is explicitly linked as >> libreadline.so.8, the same as the old base version, so python36 >> tried linking to the base version and failed because it did not >> contain the new(ish) function rl_callback_sigcleanup. >> >> There's no question I shot myself in the foot by not deleting >> the old libraries (an omission I have now remedied after a fair >> amount of thrashing around to see what was wrong), but it might >> have made my life a little easier if the port devel/readline >> linked itself as libreadline.so.9 instead of 8. Is there a >> recommended practice (or should there be one) to change the .so >> version when simultaneously moving a base library to ports and a >> new version? -- George > > libreadline.so is at version 8 because the current readline is 8.0. > libreadline.so.9 won't come until readline-9.0 is released. We really > can't deviate from that, because it'd still be v8 software; it'd be > like AT&T's ridiculous claim that they invented 5G by discovering the > number 5. > > # Adam > > You leave me no choice but to rail at whoever allowed "v4" readline to be installed as /lib/libreadline.so.8 back when it was in base. (I'd rather rail at that person than have to face my own omission.) -- George
signature.asc
Description: OpenPGP digital signature
