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? 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. > There are some things I want to note about the things I reverted or > changed[1]: > > - The ld hack. Seriously, what was the last version of ld that needed this? > Hell, the comment said it shoudl be removed 'soon' (for various definitions > of 'soon'). It breaks MSVC, and was a workaround for a bug in ld, and I > don't > think it has a place in MinGW. Simple enough, this change is fine if the newer binutils is fixed, though I did not get a go ahead message to commit it. > - 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. > - There's also complainst that one function I reverted makes C99 math slower. > This may be true, but the only part that needs to be fixed is the added > dependency on '__mingw_raise_matherr', which isnt related to performance. I > just reverted the whole thing since I was too lazy to properly fix it. I > will > do this properly if we can come to a consensus on a sane fix. > These reverts are very invasive, it is at the expense of GCC. It is the main reason the current patch was rejected. For a MSVC compatibility patch to be accepted, it must not change any behavior if used by GCC.
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
