This is the mail archive of the
mailing list for the binutils project.
Re: gold work on mingw/mingw64 support
- From: NightStrike <nightstrike at gmail dot com>
- To: Vladimir Simonov <sv at sw dot ru>
- Cc: Ian Lance Taylor <iant at google dot com>, binutils at sourceware dot org
- Date: Tue, 12 Apr 2011 07:35:46 -0400
- Subject: Re: gold work on mingw/mingw64 support
- References: <4D1CC5CB.firstname.lastname@example.org> <email@example.com> <4D234F4B.firstname.lastname@example.org> <email@example.com> <4D24613E.firstname.lastname@example.org>
On Wed, Jan 5, 2011 at 7:17 AM, Vladimir Simonov <email@example.com> wrote:
> On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
>> Vladimir Simonov<firstname.lastname@example.org> ?writes:
>>> IMO mremap.c, pread.c, etc. are a kind of such library.
>>> Analysis of target OS capabilities is overkill here, we
>>> know in advance - mingw doesn't have mmap and most probably
>>> won't have it.
>> Sure, but there are other systems that also don't have mmap. ?We don't
>> want to test for all of them.
>>> If __MINGW32__ looks too OS specific it may be
>>> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
>>> in config/mh-mingw. Really __MINGW32__ looks quite strange
>>> in the middle of descriptors.cc but I don't know how to do it
>>> better - fake function in mremap.h would be also strange,
>>> new fcntl.c - the same...
>> I'm complaining in part about the __MINGW32__ and in part about the
>> #ifdef. ?Apart from ENABLE_THREADS, the only #ifdefs in gold are very
>> small ones at the top of a few .cc files. ?Let's keep it that way.
> OK. Here is a version without __MINGW32__, with sys/mman.h and mmap
> function presence detection and new mmap.h/mmap.c.
> It is larger but should satisfy you requirements.
> Could you comment?
> Best regards
> Vladimir Simonov