slefupdate failure

[Ryan Schmidt]

On Apr 1, 2007, at 15:37, Massimo Di Stefano wrote:

>> Il giorno 01/apr/07, alle ore 01:15, Ryan Schmidt ha scritto:
>>
>>> On Mar 31, 2007, at 11:27, Elias Pipping wrote:
>>>
>>>> On Mar 31, 2007, at 4:59 PM, Massimo Di Stefano wrote:
>>>>
>>>>> ld: Undefined symbols:
>>>>> _rl_completion_matches
>>>>> _rl_filename_completion_function
>>>>> _rl_username_completion_function
>>>>> /usr/bin/libtool: internal link edit command failed
>>>>
>>>> Is it possible that you have readline installed in /usr/local ?
>>>
>>> To complete Elias's thought: If you do have readline in /usr/ 
>>> local, that's a problem for MacPorts. Get rid of that version of  
>>> readline, if you're not using it for anything. If you are using  
>>> it, then you'll need to temporarily move it out of the way, do  
>>> your thing with MacPorts, then move your readline back in place.  
>>> But note that you may very well need to do this each time you  
>>> want to use any part of MacPorts, which will get tedious.
>>
>> i never installed readline from source, in usr/local
>>
>> i do not know if this can be an incompatibily with other unix-tools
>> like fink or some frameworks that i've installed.
>>
>>
>>
>> i've tried to "comment #" the fink path in my .bash_profile
>> and than i restarted term.app and launch again the sefupdate  
>> command, but nothing changes.
>>
>> have you a suggestion a bout on "how check the problem" ?
>
> The error message really does point to a rogue readline somewhere  
> in your path. To see everywhere that you have readline on your  
> system, try this:
>
> find / -name '*readline*' 2>/dev/null
>
>
> this is the log :

Ok, so you can see that you have many copies of the readline  
libraries on your system. You have a static (.a) and dynamic (.dylib)  
pair in /scisoft/i386/lib:

> /scisoft/i386/lib/libreadline.5.1.dylib
> /scisoft/i386/lib/libreadline.5.dylib
> /scisoft/i386/lib/libreadline.a
> /scisoft/i386/lib/libreadline.dylib

You have a couple dynamic versions and a static version from Fink:

> /sw/lib/libreadline.4.2.dylib
> /sw/lib/libreadline.4.3.dylib
> /sw/lib/libreadline.4.dylib
> /sw/lib/libreadline.5.0.dylib
> /sw/lib/libreadline.5.dylib
> /sw/lib/libreadline.a
> /sw/lib/libreadline.dylib

You have a static version from Apple:

> /usr/lib/libreadline.dylib

You have a dynamic version in /usr/local/grasslib/lib:

> /usr/local/grasslib/lib/libreadline.5.2.dylib
> /usr/local/grasslib/lib/libreadline.5.dylib
> /usr/local/grasslib/lib/libreadline.dylib

And you do have a static version in /usr/local/lib, as was our  
suspicion initially:

> /usr/local/lib/libreadline.a

My guess is that either the one in /usr/local/lib or one of the ones  
in /sw/lib are being picked up by MacPorts, and that these readlines  
are not behaving the way MacPorts expect them to. As I said before:  
Move those out of the way (for example you could rename /usr/local  
to /usr/local-disabled, or /sw to /sw-disabled), then try your thing  
with MacPorts. Once you've succeeded doing whatever you were doing  
with MacPorts, you can move the disabled readline back where it was  
(understanding, however, that it may continue to interfere with your  
use of MacPorts until you remove it completely).