Hi folks, We cannot simply autoconf for readline for the following reasons: (a) readline comes with two incompatible APIs. (b) Apple's gcc reads /usr/local/include before /usr/include (c) Apple's ld reads /usr/lib/libreadline.dylib before /usr/local/lib/ libreadline.a when provided with -L/usr/local/lib (d) some users have an incompatible version of readline in /usr/local. In other words, if you install the incompatible version of readline available in ticket 10651 in /usr/local, I think you cannot compile *and* link the following piece of code without redefining completely the list of system includes, with -nostdinc. Which is the beginning of a nightmare. https://svn.macosforge.org/projects/macports/ticket/10651 #include <stdio.h> # include <readline/readline.h> int main(void) { void* ptr = (void*) rl_username_completion_function; return 0; } or this one: #include <stdio.h> # include <readline/readline.h> int main(void) { void* ptr = (void*) username_completion_function; return 0; } I think it's time to wonder why we autoconf for readline (and other stuff). At some point we decided that MacPorts (then darwinports) was to support MacOS X only. (I was against this decision, but here we are today; and considering that I no longer can install MacPorts on linux boxes I have access to, I would favor the use or more MacOS X technologies). Should we simply drop the autoconf options for readline? Should we just determine what's the API version of readline installed in /usr/? Should we keep users whining they cannot install MacPorts because they have a readline in /usr/local? Vincent: before you comment on this, I must say that I am not taking into consideration the C*_PATH and LIBRARY_PATH problem. In fact, I do not care about it at all, I am concerned by end-users not people with a Ph.D. in computer science who are wise enough to know that if they set these variables, it might break things and they need to unset them before compiling base/ :) Paul