public inbox for
 help / color / mirror / Atom feed
From: Bart Veer <>
To: John Dallaway <>
Subject: Re: eCos 3.0 beta 1 remaining issues
Date: Wed, 25 Mar 2009 12:22:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (message from John Dallaway on 	Wed, 25 Mar 2009 11:01:16 +0000)

>>>>> "John" == John Dallaway <> writes:

    John> eCos maintainers

    John> I think the eCos 3.0 branch is now good for a final release.
    John> Thank you to all those who have helped in resolving the last
    John> few Bugzilla issues. I have appended notes on the action
    John> taken. I have also attached a draft version of the release
    John> notes.

    John> If you have any comments or concerns, please raise them by
    John> the end of Thursday 2009-03-25. I will then proceed with
    John> generating the final release.

During QA testing of an upcoming eCosPro release, Ross has found a
problem in the C library's signal package. It is fairly simple to

  ecosconfig new pc default   (any target using a recent compiler will do)
  ecosconfig add fileio
  make tests

The build will fail with duplicate definitions of
cyg_libc_signals_lock() and _unlock(). The problem is caused by this

    2008-12-24  Andrew Lunn  <>

	* include/signal.inl: (cyg_libc_signals_[un]lock): remove the
	static from these inline functions which are used by the none
	static inline signal() and raise().
The patch successfully eliminated some warnings but also changed the
inlining semantics of those functions. The compiler is now generating
real code for these functions, as well as inlining them, so if more
than one module tries to use signal() or raise() then you'll get
multiple definitions.

There is a simple quick fix:

Index: signal.inl
RCS file: /cvs/ecos/ecos/packages/language/c/libc/signals/current/include/signal.inl,v
retrieving revision 1.7
diff -u -p -r1.7 signal.inl
--- signal.inl	29 Jan 2009 17:49:52 -0000	1.7
+++ signal.inl	25 Mar 2009 12:02:02 -0000
@@ -102,7 +102,7 @@ extern void cyg_libc_signals_lock_do_unl
 // cyg_libc_signals_lock() //
-inline cyg_bool
+extern __inline__ cyg_bool
@@ -116,7 +116,7 @@ cyg_libc_signals_lock(void)
 // cyg_libc_signals_unlock() //
-inline void
+extern __inline__ void

This again prevents the compiler from generating real code for the
functions, so the duplicate definitions go away. I think this is a
sensible fix, but obviously it has not been tested. At this stage of
the release process I'll wait for approval before checking it in.

This also indicates a wider problem with the extensive use of C inline
functions in parts of the system. We appear to be dependent on GNU C89
inlining (see the gcc info pages, C extensions, Inline). That could
cause problems if people start messing with -std=c99 or similar
compiler flags. It also leaves us open to possible changes in gcc
behaviour - I don't know what the compiler folks are planning in this
area. However, we can worry about the wider implications later.

I have not searched for other, similar changes. Andrew, were there any
other packages where you eliminated compiler warnings by removing
"static" from inline functions.

John, Jifl: any objections to me checking in this fix?

Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  ** Visit us at ESC Silicon Valley <>  **
  ** Mar 31-2 Apr 2009, Booth 221, San Jose McEnery Convention Center **

  reply	other threads:[~2009-03-25 12:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20 11:31 John Dallaway
2009-03-25 11:01 ` John Dallaway
2009-03-25 12:22   ` Bart Veer [this message]
2009-03-25 13:05     ` John Dallaway
2009-03-25 14:37       ` Bart Veer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).