This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]


2014-12-18 21:47 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>> Date: Thu, 18 Dec 2014 15:14:48 -0500 (EST)
>> From: Kai Tietz <ktietz@redhat.com>
>> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, sellcey@imgtec.com,
>>         brobecker@adacore.com, yao@codesourcery.com,
>>         gdb-patches@sourceware.org
>>
>> > > >From the Fedora point of view MinGW64 32-bit mode seems to be a superset
>> > > >of
>> > > MinGW32 so why to care about MinGW32 anymore?  Or what do I miss?
>> >
>> > That _I_ use MinGW32?
>>
>> That is actually your problem, isn't it?
>
> I don't see it as a problem, necessarily.
>
>> The mingw-w64 target support ftw, so why not simply allow it for targets providing it, and other targets can be covered by gnulib?
>
> Sure, why not?  I wasn't objecting to that, I just provided
> information, since Jan seemed to think ftw is available everywhere.
>
>> What libraries "mingw-w64" breaks often?!?  Could you please go in detail?  I am curious to hear that, as all distributors I know (Fedora, Debian, OpenSuse, ArchLinux, ...) haven't reported this.  Or is that just one thing you have a "gut" feeling about?
>
> The latest that I saw is this:
>
>   http://lists.gnu.org/archive/html/bug-gnulib/2014-12/msg00186.html
>
> And I remember a few more lately.

Hmm, this isn't something we got reported at all.  As you are using
pthread-library based toolchain (this is a build-option, and not a
mandatory mingw-w64 thing at all) I don't see that this is a mingw-w64
venture issue at all.  Btw we (on mingw-w64) strongly recomment to use
winpthread instead, as it solves some quirks existing with other
pthread-implementations available for Win32 ... anyway later is
off-topic.

> But look, I don't want to argue, I specifically said that.  Jan asked
> why not forget about MinGW32, and I gave _my_ reasons.  You don't have
> to agree, and we don't have to convince each other.  My only request
> is that GDB doesn't drop MinGW32 support.

Sure, no problem about that.  Nevertheless I have a problem if you try
to tell people things not true.

>> Just one point here I got curious about. What you mean by ABI?  The ABI of mingw-targets is the same for all targets using gcc.  So what ABI-differences you are talking about?!?
>
> Exception handling across DLLs is one difference I know of.

This is again a build-option of gcc, and has nothing directly to do
with mingw-w64.  For example, you can find for 32-bit dw2 based
exception-handling toolchain provided by mingw-builds projects (and
some others providing for 32-bit dw2 too).  For 64-bit there is SEH,
which replaces dw2 completely.

>> > Even if there were no problems with MinGW64, I don't think we should
>> > stop supporting MinGW32 just like that, it is still a live project,
>> > and I, for one, is quite happy with it.  I hope GDB will not drop its
>> > support any time soon.
>>
>> No problem about this, but why blocking things not related to MinGW.org?
>
> I didn't, it's a misunderstanding.  Sorry if I caused it.

Ok, np.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]