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:subject:to:references:cc:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=I6GYrGPei4BiBmC8
	nAiYcCvlULvTzTb/0VxW28v5eR7uGvgNwp2b9Gx3luP8+7N1S+KfyO4rEfjKAQkM
	gKyHscPGF4Ljon1xGj4laB45BEsGNWXjuG06ioHx9Gx2aYkcckYc04X32MxxhIIw
	T+J7JXMOmdx+CECOHmOBebp1VlI=
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: Jon Turney <jon DOT turney AT dronecode DOT org DOT uk>
Subject: Re: Out of date GNU binutils, and (slightly) broken binutils 2.27
To: "Franchuk, Alex" <afranchuk AT LGSInnovations DOT com>
References: <5882821D DOT 6090000 AT LGSInnovations DOT com>
Cc: cygwin AT cygwin DOT com
Message-ID: <01e5c3e0-96e8-6efc-fdce-ec2e9d168e1a@dronecode.org.uk>
Date: Mon, 23 Jan 2017 14:10:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <5882821D.6090000@LGSInnovations.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 20/01/2017 21:33, Franchuk, Alex wrote:
> 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?).

If I understood correctly, 'nm -l' suffers from a chronic slowdown on 
x86 (but not x86_64).  This makes the cygport stage which builds 
debuginfo packages take forever for large projects.

No-one has had the time to investigate this problem.

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

Please report this issue on the binutils bugzilla.

Please include a test case, or at least an example of a defective PE 
file, and say what you think it should look like.


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