X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 6 Apr 2009 18:29:43 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: All clear [was Re: [1.7]: For the love of god, don't update!]
Message-ID: <20090406162943.GA8149@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <49D97797 DOT 9080902 AT gmail DOT com> <49DA0FE6 DOT 6020603 AT gmail DOT com> <20090406141856 DOT GA19965 AT ednor DOT casa DOT cgf DOT cx> <49DA244E DOT 3080401 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49DA244E.3080401@gmail.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Apr  6 16:48, Dave Korn wrote:
> Christopher Faylor wrote:
> > On Mon, Apr 06, 2009 at 03:21:26PM +0100, Dave Korn wrote:
> >> ...Both exes have an IAT from kernel32 importing GetACP and Get
> >> ModuleHandleA, and two single-entry IATs referencing _impure_ptr
> >> (auto-import entries, pointing into the .text section) right at the end
> >> of their .idata sections.  Where they differ is at the start of .idata;
> >> the working exe has a single import table with 111 imports from
> >> cygwin1.dll, where the failing exe has two import tables from
> >> cygwin1.dll with 101 and 10 entries respectively.
> > 
> > I mentioned that things still work this way (as they have for the last
> > eight years) when I announced the speclib rewrite and you said:
> 
>   The fact that they have worked for eight years is due to what appears only
> to be a handy coincidence rather than an architectural design principle: that
> every single library listed in between a user-specified -lc on the command
> line and the compiler-spec-added -lcygwin /happens/ not to have an import
> section.  As far as I can see it has always been incompatible with shared
> compiler language runtime libraries, which would come after user-specified
> libraries and before -lcygwin.

I'm far from an expert in this area so this might be an idea somewhere
in the range between naive and braindead, but I'm daring today:

Wouldn't it help if libc.a, libm.a etc. wouldn't export any symbols at
all?  I mean, eventually there's libcygwin.a linked in which satisfies
all of the requested symbols.  What would break if the secondary libs
pointing to cygwin1.dll would be stubs?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/