readline issue

[Vincent Lefevre]

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 at 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)