This is the mail archive of the
binutils@sourceware.org
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.5030700@sw.ru> <mcrd3oj12so.fsf@google.com> <4D234F4B.2010600@sw.ru> <mcr7hekr2q8.fsf@google.com> <4D24613E.1050807@sw.ru>
Ping
On Wed, Jan 5, 2011 at 7:17 AM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
>>
>> Vladimir Simonov<sv@sw.ru> ?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.
>>
>> Ian
>>
>
> 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
>