On Wednesday, 7 December 2011, Dave Korn wrote:
> On 07/12/2011 19:14, Christian Joensson wrote:
>> I am trying to build gcc trunk on cygwin (with the snapshot of
>> 20111207) and get this:
>
>> /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o
>> In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0,
>> from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107:
>> /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)':
>> /usr/include/sys/wait.h:77:61: error: declaration of C function 'int
>> __wait_status_to_int(const wait&)' conflicts with
>> /usr/include/sys/wait.h:75:12: error: previous declaration 'int
>> __wait_status_to_int(int)' here
>
>> make[3]: *** [ada/adaint.o] Error 1
>
>> Does thisy symptom ring a bell for anyone?
>
> Ah, I didn't see it because I'm not using the snapshot (and I haven't been
> testing C++ builds recently either).
>
>> #ifdef __cplusplus
>>
>> inline int __wait_status_to_int (int __status)
>> { return __status; }
>> inline int __wait_status_to_int (const union wait & __status)
>> { return __status.w_status; }
>
> I can see why it happens: when adaint.c #includes sys/wait.h, it's already
> one level deep inside extern "C" { ... } nesting. So those new overloads in
> sys/wait.h (snapshot version) can't be name-mangled.
>
> Any lurking standards lawyers out there? Is it valid to #include a C
> standard header inside an extern "C" block?
it's valid, but prevents overloading.
> Should the Cygwin header use
> extern "C++" on those declarations even though they're inside #ifdef
> __cplusplus, or should adaint.c not #include things inside extern "C"?
You could surround them in extern "C++", linkage specifications nest.
>
