From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12261 invoked by alias); 26 Jun 2013 14:01:03 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 12249 invoked by uid 89); 26 Jun 2013 14:01:02 -0000 X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 14:01:01 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UrqHJ-0005SV-PU for ecos-discuss@ecos.sourceware.org; Wed, 26 Jun 2013 16:00:57 +0200 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Jun 2013 16:00:57 +0200 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Jun 2013 16:00:57 +0200 To: ecos-discuss@ecos.sourceware.org From: Grant Edwards Date: Wed, 26 Jun 2013 14:01:00 -0000 Message-ID: References: User-Agent: slrn/1.0.1 (Linux) Subject: [ECOS] Re: Why does #include define a bunch of time-related symbols? X-SW-Source: 2013-06/txt/msg00026.txt.bz2 On 2013-06-25, Sergei Gavrikov wrote: > On Tue, 25 Jun 2013, Grant Edwards wrote: >> On 2013-06-25, Grant Edwards 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 '\\s+?\(\s+?\' $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