From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32035 invoked by alias); 25 Mar 2009 12:22:01 -0000 Received: (qmail 32020 invoked by uid 22791); 25 Mar 2009 12:22:00 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Mar 2009 12:21:53 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A52D860B8017; Wed, 25 Mar 2009 12:21:50 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hwX6jmAvE0K; Wed, 25 Mar 2009 12:21:49 +0000 (GMT) Date: Wed, 25 Mar 2009 12:22:00 -0000 Message-Id: From: Bart Veer To: John Dallaway CC: ecos-maintainers@ecos.sourceware.org In-reply-to: <49CA0EFC.9000104@dallaway.org.uk> (message from John Dallaway on Wed, 25 Mar 2009 11:01:16 +0000) Subject: Re: eCos 3.0 beta 1 remaining issues References: <49C37E6E.2030901@dallaway.org.uk> <49CA0EFC.9000104@dallaway.org.uk> Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-03/txt/msg00010.txt.bz2 >>>>> "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 reproduce. ecosconfig new pc default (any target using a recent compiler will do) ecosconfig add fileio enable CYGPKG_IO_SERIAL_TERMIOS_TERMIOS0 make tests The build will fail with duplicate definitions of cyg_libc_signals_lock() and _unlock(). The problem is caused by this patch: 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 cyg_libc_signals_lock(void) { #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE @@ -116,7 +116,7 @@ cyg_libc_signals_lock(void) // cyg_libc_signals_unlock() // /////////////////////////////// -inline void +extern __inline__ void cyg_libc_signals_unlock(void) { #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE 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 -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ 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 **