Re: [Bug-readline] Fix building readline on future OS X versions, and also cleanup the relevant code

[Max Horn]

On 27.01.2014, at 17:47, Chet Ramey <address@hidden> wrote:

> 
> On 1/27/14 6:32 AM, Max Horn wrote:
> > 
> > On 25.01.2014, at 23:46, Chet Ramey <address@hidden> wrote:
> > 
> >> Thanks.  The new stanza will be in bash-4.3-rc2/readline-6.3-rc2.
> > 
> > Great! But actually, perhaps a second alteration should be put in... First, 
> > a question:
> > 
> > So far I assumed that readline 6.x released are supposed to be backwards 
> > compatible in the following sense: If a binary was linked against a 
> > readline 6.x shared library, then one may later upgrade that shared library 
> > to readline 6.y for y > x and the program will still run. Or, said simple: 
> > A program linked against readline 6.2 should still work with readline 6.3, 
> > without a need for recompilation.
> > 
> > Is that correct? If no, I did it wrong all the time and it's good I finally 
> > learned!
> 
> Yes, that's the idea. Minor version number changes are supposed to maintain
> API/ABI compatibility.  It's a bug if that assumption is violated.
> 
> > But if yes, then the currently used install_name used on Mac OS X is bad: 
> > It uses the full library name libreadline.6.2.dylib, but really should be 
> > using libreadline.6.dylib.
> 
> Sure, let me see your approach.

OK, here is what I am doing in my OS X readline6 package for Fink (a dpkg based 
package manager): Instead of using

   -install_name $(libdir)/$@

in shobj-conf, I use

  -install_name $(libdir)/`echo $@ | sed "s:\\(.*\\.[0-9]\\)\\.[0-9]:\\1:"`

This parallels the logic in support/shlib-install, around line 109, which 
creates symlinks
   libFOO.x.dylib  -> libFOO.x.y.dylib
   libFOO.dylib    -> libFOO.x.y.dylib

If you see a more elegant way, please let me know.


By the way:  support/config.guess is really old (from 2009, it seems). Amongst 
other things, it does not distinguish between 32bit and 64bit OS X 
environments. Right now, that doesn't seem to be a problem, but perhaps it 
would be a good idea to update it (and perhaps also support/config.sub, which 
was last updated in 2008, it seems)


Cheers,
Max

signature.asc
Description: Message signed with OpenPGP using GPGMail