X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49C09F09.3040804@gmail.com>
Date: Wed, 18 Mar 2009 07:13:13 +0000
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
References: <20a807210903131414g62e0a53cyefd3938c3fe8af33 AT mail DOT gmail DOT com> <49BADAC1 DOT 80709 AT cwilson DOT fastmail DOT fm> <gpf7kk$2g6$1 AT ger DOT gmane DOT org> <gpfcdo$a30$1 AT ger DOT gmane DOT org> <gpgeu9$iuo$1 AT ger DOT gmane DOT org> <Pine DOT LNX DOT 4 DOT 64 DOT 0903142203230 DOT 9859 AT gremlin DOT fruitbat DOT org> <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>
In-Reply-To: <20090318053237.GA31643@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Christopher Faylor wrote:

> Your reading of the Makefile is not right.  libc.a and libm.a from
> newlib do get used in creating cygwin1.dll (obviously?).  There are
> different libc.a, libm.a, libpthread.a, libutil.a, libdl.a, and
> libresolv.a libraries which are all produced intentionally and have
> nothing to do with the creation of the dll itself.
> 
> The initial discussion of the reason for these libraries started here:
> 
> http://cygwin.com/ml/cygwin/2001-12/msg00705.html

  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.

    cheers,
      DaveK



--
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/