libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)


From: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Date: Mon, 05 Jul 2010 12:02:08 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 7/5/2010 2:48 AM, Gary V. Vaughan wrote:
> 
> Just to clarify, that isn't what I meant -- rather, "well, I disagree, and
> as you can see, despite its faults, patch X alone already makes things
> less bad than they were previously.  Is it okay if I push X in its current
> state, and then tackle Y later? I've no inclination to work on Z, but
> I'll put a reference to this thread in libtool/TODO so it isn't entirely
> forgotten."
> 
> And I believe that we'll often say "sure", or "good point, go ahead".

I see, thanks.

...
>> Since that's really slow...I figured only windows $hosts should pay that
>> penalty (even if the penalty only occurs during LT_OUTPUT).
> 
> ...which is why I suggested having the complex, hard-to-quote-properly
> implementations written directly into ltmain.m4sh, and then using
> _LT_PROG_XSI_REPLACE to overwrite them with stubs at configure time.

D'oh.  Yeah, that make sense.

>> Ack -- that's why my version was named _LT_PROG_FUNCTION_REPLACE (the
>> other was that I needed a different internal implementation of that
>> macro, as described above).
> 
> Then I can use _LT_PROG_FUNCTION_REPLACE as the new name for existing
> _LT_PROG_XSI_REPLACE?

Sure, unless you think up something better.

>> But...according to Ralf's message, this discussion is OBE. I'll revert
>> back to a revised version of the 'take 7' patch.
> 
> OBE? Order of the British Empire?  Out of Body Experience?

Overcome by events == no longer pertinent.

--
Chuck



reply via email to

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