X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 19 Mar 2009 11:31:36 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13 Message-ID: <20090319103136.GB26397@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <49BF1770 DOT 9020007 AT gmail DOT com> <49C00B83 DOT 8050302 AT gmail DOT com> <20090317222721 DOT GB1505 AT ednor DOT casa DOT cgf DOT cx> <49C07781 DOT 1090702 AT gmail DOT com> <20090318053237 DOT GA31643 AT ednor DOT casa DOT cgf DOT cx> <49C09F09 DOT 3040804 AT gmail DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C09F09.3040804@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: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 Mar 18 07:13, Dave Korn wrote: > Ah, gottit. The bug happens because the libraries are not quite correctly > constructed. When you add -lm to the link line, you see this in the map file, > in the imports section: > > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d000104.o) > > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d000000.o) (cyggcc_s_1_dll_iname) > /usr/lib/libm.a(d001286.o) math.o (pow) > /usr/lib/libm.a(d000000.o) /usr/lib/libm.a(d001286.o) (_head_libm) > /usr/lib/libcygwin.a(dll_entry.o) > (_cygwin_dll_entry AT 12) > > There's no import name chunk for libm (_libm_dll_iname), instead the head > chunk of the import table in libm.a refers to _cygwin1_dll_iname: > > DKAdmin AT ubik /usr/src/zsh2/zsh-4.3.9/.build/Src/libm > $ nm ./d000000.o > 00000000 i .idata$2 > 00000000 i .idata$4 > 00000000 i .idata$5 > 00000000 I __head_libm > U _cygwin1_dll_iname > > which means at link time it is resolved by the definition of that symbol > supplied by libcygwin.a and so the tail chunk from libm is not pulled in to > correctly 'cap off' the end of the import table. Then all the name entries > and IAT table pointers get out of sync and we get confused and overlapping > import name tables. Constructing import tables is tricky, and we can't > optimise away or share any of the .idata$x blocks. > > There are a number of ways to solve this, either by changing the undefined > symbol in the head and tail archive members, or maybe by using dlltool or ld > to generate a fresh import library rather than munging an existing one, but > I'm going AFK now to get a few hours sleep. What I'm wondering is, why did it work all these years before? Is it a bug in the new binutils? Or was it a bug in the old binutils to create working results? 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/