Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
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 <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N A9B97A11
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <11467.000501@is.lg.ua>
To: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
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: <Pine.HPP.3.96.1000430143757.1296A-100000@hp2.xraylith.wisc.edu>
References: <Pine DOT HPP DOT 3 DOT 96 DOT 1000430143757 DOT 1296A-100000 AT hp2 DOT xraylith DOT wisc DOT edu>
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