Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Mon, 1 May 2000 11:13:44 +0300 From: Paul Sokolovsky X-Mailer: The Bat! (v1.32) S/N A9B97A11 Reply-To: Paul Sokolovsky X-Priority: 3 (Normal) Message-ID: <11467.000501@is.lg.ua> To: Mumit Khan CC: cygwin AT sourceware DOT cygnus DOT com Subject: Re[2]: [mingw] Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Mumit, Sunday, April 30, 2000, 10:43:40 PM, you wrote: MK> On Sun, 30 Apr 2000, Paul Sokolovsky wrote: >> O, I used to ask Mumit Khan why he distributes such outdated, >> 19990818 binutils for mingw32, and got answer that there's bad >> attitudes of binutils maintainers towards pe frontend. Now, when >> official Cygnus release contains the same, I see that's true... MK> I take exception to this statement. The binutils maintainers may MK> not be PE hackers, and it's fair to say that most of the gurus MK> tend not to pay much attention PE as to say ELF, but saying that MK> they have "bad attitude" is entirely unfair. If I ever said anything MK> that may have suggested this "bad attitude", I certainly didn't mean MK> it in a negative way and I apologize for any misunderstanding. Sorry, of course that term is not based on anything I heard from you. Nor it carries any sense, or grounded on anything, except my personal passive vexation that even cygwin uses old binutils snapshot, stuffed into two words of private email which was not supposed to be forwarded to public. I cannot talk reasonably about something being wrong about PE with binutils simply because I never tried to submit patch directly, so cannot say that something was rejected. Moreover, look at binutils maillist shows that, if maintainers allocate theit time proportionally to requests, that PE really don't get top priority. Some little thought also makes to understand why Cygwin 1.1.0 contains your snapshot of binutils - it is very nice that first official net release (not beta) includes stable binutils, which testing with mingw32 for several months showed their liveness. MK> I for one have not submmitted some of the patches that may fix MK> problems in the PE target, and certainly have not lobbied as hard MK> as I could have to get some of the queued changes in. My usual MK> excuse is the lack of time. Please let's not point fingers, it's MK> not productive. Spirit of my message was totally optimistic: imho, never support for Win32-specific fetures in gnu-win32 was so functional and robust. Just mere listing of known problems I tried to make shows that: all they quite minor and doesn't require immediate attention to fix. But indeed, engaged in that, I forget to thank people who made that possible: Cygnus people who started all that, and specially binutils maintainers, fruits of whose work now used not only by cygwin, but all other gnu-win32 targets, DJ Delorie, who made ld -shared support for dlls, and Mumit Khan who paid attention to code/data problem and finished his long work on supporting dllexport/dllimport support in gcc, as well as all people who tested and submitted bugreports to the tools. Current gcc/binutils combination gives me only pleasant surprises. For example, I converted project which used one big dll into set of interdependent dlls. For this, it requires some magic in the headers, which hard to do right from the beginning. But gcc was quite friendly with such situation, warning me about dllimport/dllexport conflicts and selecting right one (dllexport) to go. Just couple days ago I hacked libtool into supporting interdependent dlls with it, and expected that my another hack will allow to build one dll from the interdepndent set. I was very surpised when I got two. Investigation showed that if gcc sees dllimported decalration of some var, and then definition of that var, it discards dllimported attribute, which considerably simplifies aforementioned header magic. Of course, it works only if dll built from single source, but in my personal case it really helpful, allowing me to finish with tracking dependencies first, before going to hack automake to support general case of interdependentness. MK> Regards, MK> Mumit Best regards, Paul mailto:paul-ml AT is DOT lg DOT ua -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com