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
Paul, thanks for the analysis. I see two really easy choices, either of which I would support: (1) As you say, simply "fix" the readline location. We could make it a configure option for those who really want to change it. (2) Remove the readline library from MacPorts altogether. It's used only in interactive mode, which I believe about two people have ever used. Given my druthers, I'd choose (1), but I'm happy with either solution, and certainly will listen to any other feedback people have. James On Apr 7, 2007, at 9:14 PM, Paul Guyot wrote:
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
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On 2007-04-08 13:14:42 +0900, Paul Guyot wrote:
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
This is the case under Linux, but I thought it wasn't under Mac OS X (or my test was wrong, or the conditions were slightly different...).
(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
BTW, there's the same problem with GMP under Linux. And we had many reports to the MPFR mailing-list (as MPFR uses GMP).
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/ :)
Instead of being a problem, using these environment variables should be the solution. And this is the recommended solution (or workaround, if you prefer) for MPFR if users installed a new (incompatible) GMP version in /usr/local[*]. BTW, if users installed software in /usr/local, they should care about setting environment variables in the correct way (or complain to the vendor of their development tools for not setting paths in a consistent way). [*] http://www.mpfr.org/faq.html#undef_ref1 Now, if these variables are correctly set up and MacPorts breaks, then this is a bug in MacPorts. -- 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)
participants (3)
-
James Berry
-
Paul Guyot
-
Vincent Lefevre