From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90599 invoked by alias); 22 May 2016 02:53:12 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 90564 invoked by uid 89); 22 May 2016 02:53:07 -0000 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 Received: from mdc1.cs.umass.edu (HELO csmail.cs.umass.edu) (128.119.240.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 May 2016 02:52:57 +0000 Received: from [128.119.40.243] (csvpn19.cs.umass.edu [128.119.40.243]) by csmail.cs.umass.edu (Postfix) with ESMTPSA id 280405800012412377; Sat, 21 May 2016 22:52:55 -0400 (EDT) Reply-To: moss@cs.umass.edu Subject: Re: Help debugging a dll issue References: <830e7bcd-aeb5-264e-6436-799dfa54d7a0@cs.umass.edu> To: cygwin@cygwin.com From: Eliot Moss Message-ID: Date: Sun, 22 May 2016 02:53:00 -0000 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 X-SW-Source: 2016-05/txt/msg00246.txt.bz2 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