MacPorts 1.5.2 now available

[Ryan Schmidt]

On Aug 21, 2007, at 21:15, Jay Sachs wrote:

> On Aug 21, 2007, at 8:00 PM, Bryan Blackburn wrote:
>
>> 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.
>
> What about:
>
> gcc -nostdinc \
>     -isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
>     -isystem /usr/include \
>     -isystem /System/Library/Frameworks \
>     -isystem /Library/Frameworks
>
> ? It'd be nice not to hardcode this -- it could be determined  
> dynamically by examining the output of `cpp -v` and filtering out / 
> usr/local/include. It seems possible from the man page to do the  
> same for libraries:
>
> gcc -Z -L /standard/path1 -L /standard/path2 ....

Great, if that works. I have no experience with that.

At the very least, I hope we could add something in MacPorts that  
would specifically check for a readline in /usr/local and, if  
present, advise the user about the problems, or just refuse to  
continue altogether.