gcc - missing define?

I'm building a project using gcc and coming up with a couple of missing
defines. I've tried this with both native gcc with 686 for a target and
ppc-elf-gcc with a ppc target.

When it includes stdio.h there are a couple of undefined symbols, off_t and
clock_t.

In file included from ..\a01\a0101.c:70:
/usr/include/stdio.h:232: error: parse error before "off_t"
/usr/include/stdio.h:233: error: parse error before "ftello"
/usr/include/stdio.h:362: error: parse error before "__getdelim"
/usr/include/stdio.h:363: error: parse error before "__getline"

#ifndef __STRICT_ANSI__
#ifdef _COMPILING_NEWLIB
int _EXFUN(fseeko, (FILE *, _off_t, int));
_off_t _EXFUN(ftello, ( FILE *));
#else
int _EXFUN(fseeko, (FILE *, off_t, int)); <<<<<<<<<<<<<<<<<<<
off_t _EXFUN(ftello, ( FILE *));
#endif

The "parse error" message is confusing, but the issue appears to be off_t
not being defined.
If I define it locally, the problem goes away.

I think I am missing a command line setting so they aren't included. There
appear to be a couple of different types.h files included, but apparently a
conditional isn't set right to get these enable

Here is the command line:
C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c

There are a couple of -D on the line, but they are only for the file being
built, and definitely not related to the problem.

Any ideas or suggestions on another ng to post this to?


--
Scott
Validated Software
Lafayette, CO



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4538 (20091024) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Not Really Me wrote:
> I'm building a project using gcc and coming up with a couple of missing
> defines. I've tried this with both native gcc with 686 for a target and
> ppc-elf-gcc with a ppc target.
>
> When it includes stdio.h there are a couple of undefined symbols, off_t and
> clock_t.
>
> In file included from ..\a01\a0101.c:70:
> /usr/include/stdio.h:232: error: parse error before "off_t"
> /usr/include/stdio.h:233: error: parse error before "ftello"
> /usr/include/stdio.h:362: error: parse error before "__getdelim"
> /usr/include/stdio.h:363: error: parse error before "__getline"
>
> #ifndef __STRICT_ANSI__
> #ifdef _COMPILING_NEWLIB
> int _EXFUN(fseeko, (FILE *, _off_t, int));
> _off_t _EXFUN(ftello, ( FILE *));
> #else
> int _EXFUN(fseeko, (FILE *, off_t, int)); <<<<<<<<<<<<<<<<<<<
> off_t _EXFUN(ftello, ( FILE *));
> #endif
>
> The "parse error" message is confusing, but the issue appears to be off_t
> not being defined.
> If I define it locally, the problem goes away.
>
> I think I am missing a command line setting so they aren't included. There
> appear to be a couple of different types.h files included, but apparently a
> conditional isn't set right to get these enable
>
> Here is the command line:
> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c
>
> There are a couple of -D on the line, but they are only for the file being
> built, and definitely not related to the problem.
>
> Any ideas or suggestions on another ng to post this to?


Do you have the run-tine libraries and corresponding development
headers installed in the system?

Can you translate and run a simple 'hello.c'?

---

Please understand that the run-time library (and especially stdio)
is heavily dependent on the target system.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> Not Really Me wrote:
>> I'm building a project using gcc and coming up with a couple of
>> missing defines. I've tried this with both native gcc with 686 for
>> a target and ppc-elf-gcc with a ppc target.
>>
>> When it includes stdio.h there are a couple of undefined symbols,
>> off_t and clock_t.
>>
>> In file included from ..\a01\a0101.c:70:
>> /usr/include/stdio.h:232: error: parse error before "off_t"
>> /usr/include/stdio.h:233: error: parse error before "ftello"
>> /usr/include/stdio.h:362: error: parse error before "__getdelim"
>> /usr/include/stdio.h:363: error: parse error before "__getline"
>>
>> #ifndef __STRICT_ANSI__
>> #ifdef _COMPILING_NEWLIB
>> int _EXFUN(fseeko, (FILE *, _off_t, int));
>> _off_t _EXFUN(ftello, ( FILE *));
>> #else
>> int _EXFUN(fseeko, (FILE *, off_t, int)); <<<<<<<<<<<<<<<<<<<
>> off_t _EXFUN(ftello, ( FILE *));
>> #endif
>>
>> The "parse error" message is confusing, but the issue appears to be
>> off_t not being defined.
>> If I define it locally, the problem goes away.
>>
>> I think I am missing a command line setting so they aren't included.
>> There appear to be a couple of different types.h files included, but
>> apparently a conditional isn't set right to get these enable
>>
>> Here is the command line:
>> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c
>>
>> There are a couple of -D on the line, but they are only for the file
>> being built, and definitely not related to the problem.
>>
>> Any ideas or suggestions on another ng to post this to?
>
>
> Do you have the run-tine libraries and corresponding development
> headers installed in the system?
>
> Can you translate and run a simple 'hello.c'?
>
> ---
>
> Please understand that the run-time library (and especially stdio)
> is heavily dependent on the target system.

Yes to the run-time. This is a full cygwin install. FWIW, we have tried
this on multliple systems.

I hate to admit I didn't try a hello.c, but I guess that is next. Thanks.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4538 (20091024) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Not Really Me wrote:
> Tauno Voipio wrote:
>> Not Really Me wrote:
>>> I'm building a project using gcc and coming up with a couple of
>>> missing defines. I've tried this with both native gcc with 686 for
>>> a target and ppc-elf-gcc with a ppc target.
>>>
>>> When it includes stdio.h there are a couple of undefined symbols,
>>> off_t and clock_t.
>>>
>>> In file included from ..\a01\a0101.c:70:
>>> /usr/include/stdio.h:232: error: parse error before "off_t"
>>> /usr/include/stdio.h:233: error: parse error before "ftello"
>>> /usr/include/stdio.h:362: error: parse error before "__getdelim"
>>> /usr/include/stdio.h:363: error: parse error before "__getline"
>>>
>>> #ifndef __STRICT_ANSI__
>>> #ifdef _COMPILING_NEWLIB
>>> int _EXFUN(fseeko, (FILE *, _off_t, int));
>>> _off_t _EXFUN(ftello, ( FILE *));
>>> #else
>>> int _EXFUN(fseeko, (FILE *, off_t, int)); <<<<<<<<<<<<<<<<<<<
>>> off_t _EXFUN(ftello, ( FILE *));
>>> #endif
>>>
>>> The "parse error" message is confusing, but the issue appears to be
>>> off_t not being defined.
>>> If I define it locally, the problem goes away.
>>>
>>> I think I am missing a command line setting so they aren't included.
>>> There appear to be a couple of different types.h files included, but
>>> apparently a conditional isn't set right to get these enable
>>>
>>> Here is the command line:
>>> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c
>>>
>>> There are a couple of -D on the line, but they are only for the file
>>> being built, and definitely not related to the problem.
>>>
>>> Any ideas or suggestions on another ng to post this to?
>>
>> Do you have the run-tine libraries and corresponding development
>> headers installed in the system?
>>
>> Can you translate and run a simple 'hello.c'?
>>
>> ---
>>
>> Please understand that the run-time library (and especially stdio)
>> is heavily dependent on the target system.
>
> Yes to the run-time. This is a full cygwin install. FWIW, we have tried
> this on multliple systems.
>
> I hate to admit I didn't try a hello.c, but I guess that is next. Thanks.


As far as I know, Cygwin does not run PPC code.

--

Tauno Voipio
tauno voipio (at) iki fi

Not Really Me wrote:
[ ... ]
> The "parse error" message is confusing, but the issue appears to be off_t
> not being defined.
> If I define it locally, the problem goes away.
>
> I think I am missing a command line setting so they aren't included.
> There appear to be a couple of different types.h files included, but
> apparently a conditional isn't set right to get these enable
>
> Here is the command line:
> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c
>
> There are a couple of -D on the line, but they are only for the file being
> built, and definitely not related to the problem.
>
> Any ideas or suggestions on another ng to post this to?

One thing to try is to grep through the include directories to find out
where the symbol is defined, like

cd c:\libsrc34\inc
grep -R off_t *.h

If it's been hidden somewhere a bit non-standard, that might pull it out.

ISTR that off_t is the type returned by ftello, and used by lseek, if that's
any help.

http://opengroup.org/onlinepubs/0079...xsh/fseek.html
has handy docs for this type of thing.

Mel.

Not Really Me wrote:

> When it includes stdio.h there are a couple of undefined symbols, off_t and
> clock_t.
>
> In file included from ..\a01\a0101.c:70:
> /usr/include/stdio.h:232: error: parse error before "off_t"
> /usr/include/stdio.h:233: error: parse error before "ftello"
> /usr/include/stdio.h:362: error: parse error before "__getdelim"
> /usr/include/stdio.h:363: error: parse error before "__getline"

I don't quite agree that these symptoms match the conclusion preceding
them...

Note that it says "parse error _before_". More often than not, that
means the actual problem really is strictly before the quoted token.

In this case, my primay suspect would be the _EXFUN macro. I suggest
you acquire pre-processor intermediate output (just add options
-save-temps and -dD to your existing compiler invokation) and look at
what these lines actually turned into. As a side effect, you'll also
learn which edition of a types.h header you ended up including.

> Here is the command line:
> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c

Just on the off chance it'll make a difference, I would suggest you use
forward slashes, and consider putting GCC in the path for this exercise:

gcc -c -Ic:/libsrc34/inc a0101.c

or even the fully Cygwin-ish style:

gcc -c -I /cygdrive/c/libsrc34/inc a0101.c

And unless your target is actually i686-pc-cygwin or i686-pc-mingw,
which I guess to be somewhat unlikely, you'll have to give this
additional options so it avoids pulling in stuff specific to those
platforms (-nostdinc, a -m specification, ...)

> There are a couple of -D on the line, but they are only for the file being
> built, and definitely not related to the problem.

That's easy for you to say, with nobody else allowed a chance at
checking it...

Hans-Bernhard Bröker wrote:
> Not Really Me wrote:
>
>> When it includes stdio.h there are a couple of undefined symbols,
>> off_t and clock_t.
>>
>> In file included from ..\a01\a0101.c:70:
>> /usr/include/stdio.h:232: error: parse error before "off_t"
>> /usr/include/stdio.h:233: error: parse error before "ftello"
>> /usr/include/stdio.h:362: error: parse error before "__getdelim"
>> /usr/include/stdio.h:363: error: parse error before "__getline"
>
> I don't quite agree that these symptoms match the conclusion preceding
> them...
>
> Note that it says "parse error _before_". More often than not, that
> means the actual problem really is strictly before the quoted token.
>
> In this case, my primay suspect would be the _EXFUN macro. I suggest
> you acquire pre-processor intermediate output (just add options
> -save-temps and -dD to your existing compiler invokation) and look at
> what these lines actually turned into. As a side effect, you'll also
> learn which edition of a types.h header you ended up including.
>
>> Here is the command line:
>> C:\cygwin\bin\gcc -c -IC:\libsrc34\inc a0101.c
>
> Just on the off chance it'll make a difference, I would suggest you
> use forward slashes, and consider putting GCC in the path for this
> exercise:
> gcc -c -Ic:/libsrc34/inc a0101.c
>
> or even the fully Cygwin-ish style:
>
> gcc -c -I /cygdrive/c/libsrc34/inc a0101.c
>
> And unless your target is actually i686-pc-cygwin or i686-pc-mingw,
> which I guess to be somewhat unlikely, you'll have to give this
> additional options so it avoids pulling in stuff specific to those
> platforms (-nostdinc, a -m specification, ...)
>
>> There are a couple of -D on the line, but they are only for the file
>> being built, and definitely not related to the problem.
>
> That's easy for you to say, with nobody else allowed a chance at
> checking it...
>

I would have agreed with you if defining the off_t did not solve the
problem.

As an update I tried Tauno's suggestion of a "hello world" program and it
built correctly. I modified it to include the .h file that my other program
was including and now two files were not found, types.h and timeb.h.

I did find a bad path in my include file list (I had moved the project) and
when the path was fixed I got the off_t error again. I searched the path I
was now using and found that there were zero length copies of types.h and
timeb.h (and memory.h). This folder of include files came with the 3rd
party library I am building. I still do not understand why they had zero
len versions of these files, but at least I know the actual source of the
error. The library is almost ten years old and I build it with many
different compilers, but not gcc apparently.

Scott


Scott



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4543 (20091026) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Tauno Voipio wrote:
> Not Really Me wrote:
>> Tauno Voipio wrote:
snip
>>
>> I hate to admit I didn't try a hello.c, but I guess that is next.
>> Thanks.
>
>
> As far as I know, Cygwin does not run PPC code.

Tauno, sorry I didn't make it clear that we are cross compiling a special
run time library for a target. I found the real problem and posted that
elsewhere in this thread. Thanks. Scott



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4544 (20091026) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com