X-Recipient:	archive-cygwin AT delorie DOT com
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=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=7rp7g0kkjT7y+5QX26PNn/
	8sUF8=; b=OD/sr7/Qoy6KFz+MI3xScfdjwMLEJ3+pxcR5YYfteQOCTP2KqRfEki
	caBRelashLHrnZ08v+CzuH5lcuQPK3qJe/iX4Ah8a4ZjSqMTbD3eXhp7wMUgsAHS
	VgJixRPB2qEbYYK/lry66knuLO7vr+kTtV5izO+HvYV/tvq643xso=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=chronic, H*RU:sk:host86-, Hx-spam-relays-external:sk:host86-, H*r:sk:host86-
X-HELO:	out1-smtp.messagingengine.com
X-ME-Sender:	<xms:8w6GWEwLJ_AvTeBUCZddrhv9HcLNVmm-l5Xj8bHkW3zRdMoZ8V2BXA>
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>

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

- Raw text -