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:reply-to:subject:references:to:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=YF2nwryJDE6XYhdI bUVqLgoMYMquuSDp7sG5SHYQNEHxhDls/lGSDXeipR9oAGhVcex+BpL+Bc04pIrB jZZC3RyBYHlxVcMP092pcr5QQZrkBGui//IiHl8X3xlz3UGJm/m+xErKwBRjtZFA nR32jcmlZZbwzEzvzfeDfo+Ro5A= 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:reply-to:subject:references:to:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=FADjPq3mYHPVN9AZsdtMBY GhxuA=; b=pK/zNaTy01xsRviq87dAFCC1p1ZPN1+d+0U3kbcHYrWaDQKwhIuQG1 rIDA8EFrlSgz646YXCvbLP6T+qb4u7PRNSDzflAsDhUwHUefaEnTciUcHDI4riA5 DKVtoWVfw/4sGNttsVBEWq8S4EOAtG458+wwGbz/wed1wgr5L/LkI= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=dlls, H*f:sk:830e7bc, 5292, berber X-HELO: csmail.cs.umass.edu Reply-To: moss AT cs DOT umass DOT edu Subject: Re: Help debugging a dll issue References: <830e7bcd-aeb5-264e-6436-799dfa54d7a0 AT cs DOT umass DOT edu> To: cygwin AT cygwin DOT com From: Eliot Moss Message-ID: Date: Sat, 21 May 2016 22:52:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes On 5/21/2016 9:45 PM, René Berber wrote: > On 5/21/2016 6:30 PM, Eliot Moss wrote: > > [snip] >> I used binary search, eliminating .o files from the .dll on the thought >> that it was either a particular .o file that was leading to a problem, >> or possibly the overall size (this is a huge link!). I found that a .dll >> with 58725 section 1 symbols (as reported by objdump -t) works, and one >> with 66675 section one symbols fails. So it appears to be a size issue. > > That's telling, since USHRT_MAX (65535) may be the limit, then somewhere > there is the use of a variable of that type (unsigned short int, > uint16_t), which may be part of some specification (i.e. the format of > libraries). > > Supporting that is: https://ghc.haskell.org/trac/ghc/ticket/5292 which > mentions: > > "65536 symbols. This is the limit that Windows DLLs can handle (the > source of the limitation is that they use 16-bit integers to represent > "ordinals")" > > and also point to an interesting bug report (5 years old): > > https://sourceware.org/bugzilla/show_bug.cgi?id=12969 > > No answers, but at least an explanation. Why the maintainers did not fix this, I don't know -- would have saved me a week of effort tacking things down! The solution was to use __declspec(dllexport), sparingly, so that only a few symbols would be exported, and to drop --export-all-symbols. (How did that work before? Was the system a lot smaller?) Supposedly __attribute__((dllexport)) also works, though I did not try it -- using __declspec was more in line with code for Windows native C compilers. At least this thread may help someone in the future! Regards -- Eliot -- 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