Re: ICC compile errors

On Tue, Mar 29, 2011 at 6:30 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> 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.

-- 
    /kinkie