This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: newlib at sources dot redhat dot com, Dave Korn <dave dot korn at artimi dot com>
- Date: Thu, 29 Mar 2007 00:28:26 -0400
- Subject: Re: [PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.
- References: <008a01c77191$c3bbf460$2e08a8c0@CAM.ARTIMI.COM>
On Thu, Mar 29, 2007 at 12:35:27AM +0100, Dave Korn wrote:
>
>
> Hi Jeff, hope you had a nice break!
>
> It's a fairly complicated story, but gcc won't currently bootstrap on
>cygwin. It's a combination of three factors:
>
> - stdio.h uses 'static inline' to declare __sgetc_r (and the
>currently-ifdef'd-out __sputc_r).
> - gcc uses the -fkeep-inline-functions flag when bootstrapping.
> - libgcc doesn't link against libcygwin (and in any case should not contain a
>static copy of __sgetc_r in the .ctors section!)
>
> For background, you can browse these threads:
>
>http://cygwin.com/ml/cygwin/2007-03/msg00705.html
>http://gcc.gnu.org/ml/gcc/2007-03/msg00948.html
>http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html
>
> The problem basically is that -fkeep-inline-functions causes libgcc to have
>unresolved references to _ungetc et al. The gcc bootstrap process
>deliberately uses -fkeep-inline-functions to show up problems that would be
>caused by inline functions when bootstrapping gcc with a native (non-gcc)
>compiler, none of which match gcc's functionality of not emitting the body of
>a static inline function unless it has to. So, the first possibility is to
>switch to using extern inline, which doesn't ever emit the function body, not
>even with -fkeep-inline-functions. Problem is, the meaning of extern inline
>is shortly changing to be c99-compliant. So, we end up using a feature test
>to define a macro that means "this function can be omitted if possible". This
>fixes gcc bootstrap for cygwin.
>
> I've tested this to the extent of building winsup and running the cygwin
>testsuite with and without the patch and verifying that it doesn't break the
>build or cause any change in the testsuite results, and verifying that the
>change makes it into the installed stdio.h after "make install". More testing
>would be good, though. It's not a neutral change; replacing a static inline
>with an extern inline could I guess cause link errors in some projects.
>Should it perhaps be conditionalised on __CYGWIN32__ or something? Are there
>maybe some newlib-linux targets that might be affected by this as well?
If it is ifdef'ed, it should be #ifdef __CYGWIN__ please. __CYGWIN32__
is violently deprecated.
cgf