On Aug 21, 2007, at 07:31, Tommaso Urli wrote:
Ok, I renamed libreadline.a and tried "port install readline". Now let's see if it works.
On Aug 21, 2007, at 12:16, Tommaso Urli wrote:
As I said I reinstalled redaline through MacPorts, but still:
frodo:/usr/local/lib root# port selfupdate [snip] cc -dynamiclib -L/usr/local/lib Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o fs-traverse.o strcasecmp.o vercomp.o filemap.o sha1cmd.o compat.o curl.o rmd160cmd.o readline.o uid.o -o Pextlib.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4 -L/usr/local/lib -L/usr/lib -lcurl -lssl -lcrypto -lz -lcrypto -lreadline ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _rl_completion_matches _rl_filename_completion_function _rl_username_completion_function /usr/bin/libtool: internal link edit command failed make[2]: *** [Pextlib.dylib] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1
libreadline.a is the statically-linked library. Are you sure there aren't also any dynamically-linked libraries of readline in /usr/ local/lib? Their names would be libreadline.*.dylib. You'll also want to check for and remove any readline includes in / usr/local/include. Others have encountered this problem before; see: http://rob.cogit8.org/blog/2006/Nov/06/macports-and-removing-fink/ http://lists.macosforge.org/pipermail/macports-users/2007-May/ 003230.html I guess we should write a FAQ entry about it. Anyone wanna do that? Devs: I think this problem occurs because MacPorts needs a newer version of readline than the one you have in /usr/local. Couldn't we add a check to ./configure to make sure the correct version of readline is available, and issue a sensible error message if not, rather than failing with this unfortunate undefined symbols error later on? Or, couldn't we instruct configure never to look for anything in /usr/local? I believe the latter has been suggested before but I don't remember the outcome.
On Aug 21, 2007, at 3:33 PM, Ryan Schmidt wrote: ...
Devs: I think this problem occurs because MacPorts needs a newer version of readline than the one you have in /usr/local. Couldn't we add a check to ./configure to make sure the correct version of readline is available, and issue a sensible error message if not, rather than failing with this unfortunate undefined symbols error later on? Or, couldn't we instruct configure never to look for anything in /usr/local? I believe the latter has been suggested before but I don't remember the outcome.
The last time I looked into something like this, it was my conclusion that /usr/local is considered special by gcc and hence, you can't remove it from the list. It would definitely be a great thing if this has changed, or I was wrong, because having MP tell gcc to always ignore /usr/local would definitely solve many problems, the recurring readline issue being one of the most common of course. Bryan
On 2007-08-21 16:33:11 -0500, Ryan Schmidt wrote: [...]
ld: Undefined symbols: _rl_completion_matches _rl_filename_completion_function _rl_username_completion_function /usr/bin/libtool: internal link edit command failed make[2]: *** [Pextlib.dylib] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1
libreadline.a is the statically-linked library. Are you sure there aren't also any dynamically-linked libraries of readline in /usr/local/lib? Their names would be libreadline.*.dylib.
I recall that the same problem could also happen due to the libreadline in /opt/local/lib (i.e. the one installed by MacPorts). I don't know if this is still the case, though. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Aug 22, 2007, at 11:04 AM, Vincent Lefevre wrote:
libreadline.a is the statically-linked library. Are you sure there aren't also any dynamically-linked libraries of readline in /usr/local/ lib? Their names would be libreadline.*.dylib.
I recall that the same problem could also happen due to the libreadline in /opt/local/lib (i.e. the one installed by MacPorts). I don't know if this is still the case, though.
That shouldn't be the case anymore (if it is, it's a bug). I think when you stumbled upon that problem it was due to some environment variables that you had set that macports' build process didn't sanitize. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (4)
-
Bryan Blackburn
-
Daniel J. Luke
-
Ryan Schmidt
-
Vincent Lefevre