[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] making shared link failures fatal

From: Chet Ramey
Subject: Re: [Bug-readline] making shared link failures fatal
Date: Sat, 26 Mar 2011 14:43:15 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

On 3/26/11 2:03 PM, Mike Frysinger wrote:
> On Sat, Mar 26, 2011 at 1:47 PM, Chet Ramey wrote:
>> On 3/25/11 2:55 PM, Mike Frysinger wrote:
>>>> The question is whether or not a failure to build the shared version of
>>>> readline should cause the build to fail, even if the static library is
>>>> created successfully.
>>> i cant see how ignoring the shared link is sane anymore.  what
>>> reasonable OS doesnt use shared libraries anymore ?
>> That doesn't have anything to do with it.  If I've made a mistake in
>> shobj-conf or shlib-install, should that kill the build?  It's ok if
>> your answer is "yes," and I'm open to the discussion.
> i think it should die.  otherwise, i imagine some people wont notice.
> if they're installing by hand, they'll probably clobber the old files
> (headers/static), and could possibly continue using the old shared
> library.  if they're installing via a package manager, the guy taking
> care of that can easily include the patch so that the end person never
> notices.

That's a reasonable argument.

>>> or even better, why not just convert to libtool already ?  every other
>>> major project out there has long ago switched to libtool.  that would
>>> detect whether the target supports shared libraries at configure time
>>> and disable it by default.
>> I'd advise you to take a look at it before shooting from the hip next
>> time.  The readline build system has always detected supported and
>> unsupported systems at configure time.  It's reasonable to have a
>> discussion about this, but don't pull bogus arguments out of your ass
>> to do it.
> i dont see any arguments pulled from my ass here, so i dont know what
> you're referring to.

Really?  The only reason you supplied above was that libtool detects
whether or not shared libraries are supported at configure time.  The
existing system already does that, so it's a wash and not a compelling
argument to switch.  If that were the only reason, it would actually be
an argument against spending the time and effort.  Since you presumably
wrote that because you didn't check whether or not the existing scripts
do it -- you would not have had you looked -- it's an argument you pulled
out because you thought it was true.

> libtool has obvious advantages -- you no longer
> have to maintain your own hand coded list of targets/flags/etc... for
> how to build up shared code.  what reason is there nowadays for doing
> so other than "we already know what we have today" ?  i dont see any
> downsides to the conversion other than time to implement.

You're correct -- it's mostly inertia, that the current system does
the job, and the fact that readline and bash can share that code.  The
current scripts are also much smaller, much simpler, and overall much
more lightweight than any libtool solution.  My impression of libtool
was a huge, complex, and fragile system that I simply didn't want to
incorporate -- my time was better spent on other things.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]