On 16/06/2012 11:25 PM, JonY wrote: > On 6/17/2012 10:10, Derek Buitenhuis wrote: >> On 16/06/2012 9:47 PM, JonY wrote: >>> On 6/17/2012 09:17, Derek Buitenhuis wrote: >>>> So, lately there's been some discussion relating to MSVC support in >>>> libmingwex. >>>> >>>> Yes, I've been busy lately. And frankly, I stopped caring too, but people >>>> complained, so here's an email to the mailing list as people have >>>> requested. >>>> The goal of this email to to iron out design issues before actually >>>> deciding >>>> on an approach for the patches. People have suggested libmingwex-msvc.a, >>>> and >>>> I think wholeheartedly believe this is wrong. >>>> >>> >>> Why is it wrong? >> >> A few reasons: >> >> 1) If they can work together as one, there is no reason to split them. I >> strongly >> believe this is feasible. There are only a few things preventing this. > > This will not happen due to the seriously invasive changes you made. It > will affect GCC, it's primary consumer.
I think you need to forget about those changes for a second. Forget them. They
don't exist right now. I'm saying it is feasible to do this in some way, but NOT
with my existing changes.
>> 2) It is a maintenance nightmare.
>
> How so? You mentioned about __mingw_raise_matherr symbol fix, so just
> make a MSVC compatible version that does not use it, specifically for MSVC.
I'd rather figure out a fix that does -not- require separate libs. The
dependency
on __mingw_raise_matherr is not MSVC-specific. It's a bad design choice, period,
and should be fixed regardless. I don't know why you are so gung-ho about moving
any possible changes into their own lib, if they can benefit both sides. I'm
sure
it can be done in a way so that both sides work, and no functionality is lost
on either side.
>>> Please understand that linking with MSVC has never been encouraged, any
>>> working code is by pure coincidence, you're likely the first to actively
>>> pursue it.
>>
>> Other people have been doing this for years. Patching MinGW even. I'm
>> just the first to bring it to you, likely.
>
> Mixing compilers at the code object level is hardly a smart thing to do,
> you should be using strictly controlled DLL interfaces (or any other
> well defined interface at the OS level).
While in theory I agree with this sentiment, I also don't think it should
be purposely broken. It did and can work.
>>>> - The rest of the commits all address one issue: Someone introduced a
>>>> dependency
>>>> on libmingw32 into libmingwex. This is bad design and, as far as im
>>>> concerned,
>>>> wrong. I'd like to discuss the best way to handle fixing this-- that is,
>>>> if I
>>>> don't get flamed into oblivion first.
>>>> - Somebody mentioned that there is a plan to start reimplementing msvcrt
>>>> functionality in libmingwex, and thus it will break linkign again. This
>>>> is
>>>> wrong in so many ways. Let me quote wikipedia: "These issues have been
>>>> partially mitigated by the implementation of a C99 compatibility library,
>>>> libmingwex, [...]". Yes. libmingwex is a -compatability library-, and
>>>> absolutely the wrong place to do this.
>>>
>>> Where do you propose mingw extensions go? Some of them is there to fix
>>> msvcrt C99 issues.
>>
>> Can you elaborate on which MinGW extensions would have to reimplement parts
>> of msvcrt?
>>
>
> See the lib{32,64}/msvcrt.def files in SVN for mingw-w64-crt,
> particularly the functions marked as DATA.
Can you be a little less vague please?
>> I would like it if you can:
>>
>> 1) Define which behavior you are referring to, specifically, and why it MUST
>> NOT
>> BE CHANGED no matter what.
>
> The math parts that you reverted changes program behavior if linking is
> done by GCC. A smaller change with ifdefs would be better. The compiled
> code with the activated ifdefs will live in libmingwex-msvc.
I've stated numerous times that this needn't be. It can be fixed sanely,
and without ifdefs. I think it's possible for the GCC side to be functionally
equivalent, and to also fix the MSVC side at the same time. The only problem
right now is that the error raising used is located in libmingw32. I haven't
had much time lately to look into this deeper. I think you need to stop fixating
on "your existing changes are invasive" and focus more on "a good design to fix
this that makes everyone happy". Again, most of the math stuff doesn't
-actually-
need to be changed.
>> 2) Give me your opinion on the matherr part of it -- would you be against
>> moving it
>> to mingwex instead of mingw32? This is relevant to the dependency issue I
>> noted
>> above. I don't think libmingwex should depend on libmingw32...
>
> Yes, if it does not affect GCC behavior. Kai, any inputs?
>
> If any MSVC compatibility change makes it into mingw-w64, you will have
> to volunteer to maintain it to prevent it from becoming dead code and
> consequently removed; there aren't anybody else working with MSVC or
> have MSVC compatibility in mind.
Sure.
- Derek
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
