DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-id:content-transfer-encoding:mime-version; q=dns; s=
	default; b=Ix96tlkPbZSGms90IKgjR0AGf91HyUg2fTrsBYgpzR7seIROpwhQA
	Mib03DrT6kpPKhqoX0DbtNIzDEyXUSqot/F2/d9jdnNorZAQV07VTuDWK3/ai8tU
	AzTVjKIWz6t3KsN+ZKCuwjSTs76sGgmdMfm66OBBn7LOtPwi2Yjjls=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Franchuk, Alex" <afranchuk AT LGSInnovations DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Out of date GNU binutils, and (slightly) broken binutils 2.27
Date: Fri, 20 Jan 2017 21:33:18 +0000
Message-ID: <5882821D.6090000@LGSInnovations.com>
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-ID: <9456E14A3089F047965C726886457F30 AT lgsinnovations DOT com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id v0KLXdkc016805

Hello,

I've been responsible for porting a large [primarily] C++ project from 
Linux to Cygwin. This project generates object files at one point in the 
build process which exceed the object file symbol count limit (around 
32k, but if I recall correctly there was actually a binutils bug 
limiting this further to 16k). As such, I needed an assembler and linker 
that supported the windows big-obj format. That was added in more recent 
versions of GNU binutils, however the version that is available in the 
Cygwin repository is discouragingly old. So the first point I want to 
make is to ask whether the maintainers of Cygwin binutils can be pinged 
to update the supported version, or to know why the last supported 
version is from 2014 (is there something that breaks with newer versions?).

The next step I took was to get a recent version (2.27) that does 
support big-obj, compile it on the system, point gcc toward that 
installation, and try to proceed from there. This fixed the big-obj 
issue, and for the most part lots of the sub-projects were working just 
fine. But one sub-project in particular is having an issue: the 
resulting binary (a dll, in this case) has a flaw in the import lookup 
table (.idata subsection). The import lookup table of one 
runtime-dependent DLL is overwriting the null entry that *ends* the 
previous DLL's table. So, the previous DLL tries to link with a symbol 
that is actually contained in the other DLL, while the other DLL still 
correctly points to needing that symbol as well. In other words, this 
makes it impossible to use the resulting DLL, because it has a dependent 
symbol that will never be resolved correctly. It's worth noting that 
lots of other things link correctly without this bug, and other DLLs 
within that file do not have import lookup tables that overrun each 
other. I thought it would be reasonable to send to this mailing list 
because, from what I read in the binutils source, it seemed like most of 
the pe/pe+ code that has been added to binutils was from Cygwin 
developers. I tried to find the root of the problem, but after hours of 
searching and debugging the linker and BFD code, I haven't found the 
source of the discrepancy.

Any advice would be greatly appreciated!
-Alex Franchuk
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple