Re: ICC compile errors

On 06/04/11 16:55, Kinkie wrote:
> On Tue, Mar 29, 2011 at 6:30 PM, Alex Rousskov wrote:
>> On 03/25/2011 05:01 PM, Amos Jeffries wrote:
>>> On 25/03/11 04:51, Alex Rousskov wrote:
>>>> On 03/24/2011 08:13 AM, Amos Jeffries wrote:
>>>>> I've got it to the point where all the simple ones appear gone.
>>>>>
>>>>> Anyone have a clue what this means? and how we fix it?
>>>>>
>>>>> The closest I could get was that it did not like the system definitions
>>>>> inside<iosfwd>
>>>>>
>>>>>
>>>>> /usr/include/c++/4.1.2/cstdio(109): error: the global scope has no
>>>>> "fgetpos"
>>>>> using ::fgetpos;
>>>>> ^
>>>>> /usr/include/c++/4.1.2/cstdio(111): error: the global scope has no
>>>>> "fopen"
>>>>> using ::fopen;
>>>> ...
>>>>> /usr/include/c++/4.1.2/cstdio(138): error: the global scope has no
>>>>> "tmpfile"
>>>>> using ::tmpfile;
>>>>> ^
>>>>> compilation aborted for ../../../src/base/AsyncJob.cc (code 2)
>>>>
>>>>
>>>> If the above "using ::foo" lines are inside the /usr/include/ header
>>>> file (included by<iosfwd>?), then the compiler seems to be complaining
>>>> that said functions are not declared, making the "using" statements
>>>> invalid. This would be a compiler [header file] bug then.
>>>>
>>>> Try #including<stdio.h> in Squid files _before_ including<iosfwd>. If
>>>> it helps, we would need to provide an<iosfwd> wrapper as the final
>>>> solution.
>>>>
>>>
>>> No luck I'm afraid.
>>>
>>> stdio.h is already include earlier by the compat headers.
>>> I tried it explicitly directly ahead, and cstdio as well. Both showed
>>> no change.
>>
>> Hm.. Perhaps some macros are messing things up? How is fgetpos() declared?
>>
>> As an experiment, you can try declaring fgetpos yourself, before
>> including the failing headers and see whether your declaration will
>> conflict with something inside system headers, to give you more clues
>> for a workaround.
>>
>> Here is a minimal test case that can be inserted and modified as needed:
>>
>> #include<stdio.h>
>> // our own declaration; should not be needed and may conflict
>> int fgetpos(FILE *stream, fpos_t *pos);
>>
>> namespace TestSpace {
>> // should work unless fgetpos is a macro
>> using ::fgetpos;
>> }
>
> I've checked the issue some more, it comes from 64bit-ness in file
> operations: stdio.h in that case on provides
> fgetpos64, fopen64 if __USE_FILE_OFFSET64 is defined. It then checks
> whether a gcc-specific __REDIRECT macro is available (defined in
> sys/cdefs.h, depending on __GNUC__ begin available). If it is not
> available, it does a preprocesso #define. Which finally<cstdio>
> undefines, with this comment: "// Get rid of those macros defined in
> <stdio.h> in lieu of real functions.". When it does a namespace
> redirection ("namespace std { using ::fgetpos; }") it goes blam, as
> fgetpos64 is available, while fgetpos is not.
>
> To fix it, we need to supply global functions matching those
> signatures (not macros).
>
> e.g.
>
> #include<stdio.h>
> #if defined(__USE_FILE_OFFSET64)&&!defined(__REDIRECT)&& defined(fgetpos)
> #undef fgetpos
> int fgetpos (FILE * f, fpos64_t *p) { return fgetpos64(f,p); }
> #endif
> #include<cstdio>
>
> This every time we use<cstdio> (directly or indirectly).
>
> This is triggered by us defining -D_FILE_OFFSET_BITS=64 when
> --enable-large-files configure is used.
>
>

Thank you for this excellent analysis kinkie.

I'm now testing a patch that adds this hack to libcompat.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.6