[ECOS] Why does #include <cyg/io/eth/eth_drv> define a bunch of time-related symbols?

[ECOS] Why does #include <cyg/io/eth/eth_drv> define a bunch of time-related symbols?

[Grant Edwards]

I'm working on a new Ethernet driver.  eCos kernel/libs (including the
new drive) build fine. But, when I try to link an application I get a
bunch of errors because some time-related functions are defined twice.
They're defined in libtarget where they're supposed to be, but they're
also getting defined in the object file for my Ethernet driver [and I
can't figure out why].

However, my ethernet driver file has been stripped down to nothing but
a handful of #include directives:

------------------------------lpc1800_ether.c------------------------------
#include <pkgconf/system.h>
#include <cyg/infra/diag.h>
#include <cyg/io/eth/netdev.h>
#include <cyg/io/eth/eth_drv.h>
---------------------------------------------------------------------------

If I comment out the last line (eth_drv.h), the problem goes away (the
object file is empty).  With that line, I get the duplicate time
functions showing up in what should be an empty object file.  

Why?


Here's some info on the object file that's generated with eth_drv.h
included:

$ size [...]/current/src/devs_eth_arm_lpc1800_lpc1800_ether.o
   text    data     bss     dec     hex filename
   1740       0       0    1740     6cc [...]/current/src/devs_eth_arm_lpc1800_lpc1800_ether.o

$ nm -a [...]/current/src/devs_eth_arm_lpc1800_lpc1800_ether.o
00000000 t $a
[...]
00000000 N .debug_ranges
00000000 N .debug_str
00000000 t .text
00000000 t .text.asctime
00000000 t .text.asctime_r
00000000 t .text.ctime
00000000 t .text.ctime_r
00000000 t .text.cyg_libc_time_getzoneoffsets
00000000 t .text.cyg_libc_time_setdst
00000000 t .text.cyg_libc_time_setzoneoffsets
00000000 t .text.difftime
00000000 t .text.gmtime
00000000 t .text.localtime
00000000 t .text.localtime_r
00000000 t .text.strcoll
         U __aeabi_i2d
00000000 T asctime
00000000 T asctime_r
00000000 T ctime
00000000 T ctime_r
         U cyg_libc_time_asctime_buf
         U cyg_libc_time_current_dst_offset
         U cyg_libc_time_current_dst_stat
         U cyg_libc_time_current_std_offset
         U cyg_libc_time_day_name
00000000 T cyg_libc_time_getzoneoffsets
         U cyg_libc_time_gmtime_buf
         U cyg_libc_time_itoa
         U cyg_libc_time_localtime_buf
         U cyg_libc_time_month_name
         U cyg_libc_time_normalize_structtm
00000000 T cyg_libc_time_setdst
00000000 T cyg_libc_time_setzoneoffsets
00000000 T difftime
00000000 T gmtime
         U gmtime_r
00000000 T localtime
00000000 T localtime_r
00000000 a lpc1800_ether.c
         U memcpy
         U strcmp
00000000 T strcoll


-- 
Grant Edwards               grant.b.edwards        Yow! I'm a fuschia bowling
                                  at               ball somewhere in Brittany
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Why does #include <cyg/io/eth/eth_drv> define a bunch of time-related symbols?

[Grant Edwards]

On 2013-06-25, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> I'm working on a new Ethernet driver.  eCos kernel/libs (including the
> new drive) build fine. But, when I try to link an application I get a
> bunch of errors because some time-related functions are defined twice.
> They're defined in libtarget where they're supposed to be, but they're
> also getting defined in the object file for my Ethernet driver [and I
> can't figure out why].

It's cause by compiling the driver with the -std=gnu99 flag.  I a big
fan of limiting the scope of variables and like to use this sort of
construct:

  for (int i=0; i<whatever; ++i)
    {
      // "i" is only visible inside this block    
    }

It appears that eCos header files don't work right when you compile
with C99 semantics...
    
-- 
Grant Edwards               grant.b.edwards        Yow! I just forgot my whole
                                  at               philosophy of life!!!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Why does #include <cyg/io/eth/eth_drv> define a bunch of time-related symbols?

[Sergei Gavrikov]

Hi Grant

On Tue, 25 Jun 2013, Grant Edwards wrote:

> On 2013-06-25, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> 
> > I'm working on a new Ethernet driver.  eCos kernel/libs (including the
> > new drive) build fine. But, when I try to link an application I get a
> > bunch of errors because some time-related functions are defined twice.
> > They're defined in libtarget where they're supposed to be, but they're
> > also getting defined in the object file for my Ethernet driver [and I
> > can't figure out why].
 
I guess you catch some kind of "Library Issue"

  http://gcc.gnu.org/c99status.html

> It's cause by compiling the driver with the -std=gnu99 flag.  I a big
> fan of limiting the scope of variables and like to use this sort of
> construct:
> 
>   for (int i=0; i<whatever; ++i)
>     {
>       // "i" is only visible inside this block    
>     }
> 
> It appears that eCos header files don't work right when you compile
> with C99 semantics...

Not only libraries. Many people (me too) are surprised when they look at
this table http://en.wikipedia.org/wiki/C99#Implementations -- very few
compilers are ready for C99.

Of course, if you (your fingers :-) have a habit... Well, you know about
C and C++ mix in eCos. If you like for-scope declarations then you would
use standard C with a bit of C++ sugar instead C99, eCos way:

  % grep -Er '\<for\>\s+?\(\s+?\<int\>' $ECOS_REPOSITORY

Though then here and there human can miss the needed extern "C"
declarations and that is a penalty for the only one C99 habit.

Sergei

> -- 
> Grant Edwards               grant.b.edwards        Yow! I just forgot my whole
>                                   at               philosophy of life!!!
>                               gmail.com            
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Why does #include <cyg/io/eth/eth_drv> define a bunch of time-related symbols?

[Grant Edwards]

On 2013-06-25, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> On Tue, 25 Jun 2013, Grant Edwards wrote:
>> On 2013-06-25, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>> 
>> > I'm working on a new Ethernet driver.  eCos kernel/libs (including the
>> > new drive) build fine. But, when I try to link an application I get a
>> > bunch of errors because some time-related functions are defined twice.
>> > They're defined in libtarget where they're supposed to be, but they're
>> > also getting defined in the object file for my Ethernet driver [and I
>> > can't figure out why].
>  
> I guess you catch some kind of "Library Issue"
>
>   http://gcc.gnu.org/c99status.html

Sort of.  Those "library issues" refer to things in glibc that don't
yet meet the C99 standard.  There are new features/functions/macros
that haven't been added yet to glibc. You can still build applications
in C99 mode and everything works great (as long as you don't depeond
the new C library feature to be there). I've been using gcc C99 mode
to build large Linux applications with both uclibc and glibc for
years, and have never had any problems at all.

The problem I ran into with eCos is that a header file is actually
"broken" in that it doesn't even allow the file to be compiled
correctly.

> Not only libraries. Many people (me too) are surprised when they look
> at this table http://en.wikipedia.org/wiki/C99#Implementations --
> very few compilers are ready for C99.

I'm not a language-lawyer, but in my experience C99 mode in gcc,
glibc, and uclibc has been perfectly usable for years.  There may be a
few obscure features that haven't yet been added yet, but you can turn
on C99 mode and use the features that are there without any problems.

> Of course, if you (your fingers :-) have a habit... Well, you know
> about C and C++ mix in eCos. If you like for-scope declarations then
> you would use standard C with a bit of C++ sugar instead C99, eCos
> way:
>
>   % grep -Er '\<for\>\s+?\(\s+?\<int\>' $ECOS_REPOSITORY
>
> Though then here and there human can miss the needed extern "C"
> declarations and that is a penalty for the only one C99 habit.

I could do that. I'd rather try to fix the eCos header files so they
don't break when you use C99 mode. :)

-- 
Grant Edwards               grant.b.edwards        Yow! if it GLISTENS,
                                  at               gobble it!!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss