This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Success with MinGW and AVR and LTO - almost


2010/1/10 Kai Tietz <ktietz70@googlemail.com>:
> 2010/1/10 Andrew Hutchinson <andrewhutchinson@cox.net>:
>>
>>
>> Kai Tietz wrote:
>>>
>>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>>> handled). For O_BINARY the common approach here is to do the following
>>> condifition before use:
>>>
>>> #ifndef O_BINARY
>>> #define O_BINARY 0
>>> #endif
>>>
>>> This is a pattern pretty often used. To rely here on binmode.o is a
>>> way, too, but it is the most ugly one, too. It affects any file open,
>>> which isn't necessarily wanted.
>>>
>>> Cheers,
>>> Kai
>>>
>>>
>>
>> Is LTO really the only place gcc needs ?binary access to files for build of
>> cross compiler?
>
> I am not sure here. But in general gcc uses just text files/streams
> for input and output. AFAIR there was used in the past _O_BINARY in
> gcc's frontend, but well I can be wrong here.
> Binary mode fopen are used at the moment in gcov-io.c, genchecksum.c,
> graphite-sese-to-poly, toplev.c (for asm_out_file) and c-pch.c as here
> binary data is written/red.

Well, open call there aren't that much but point of interest is in
'c-pch.c:  fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
O_BINARY, too. See also for pattern in libiberty mkstemps.c

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination


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