This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.

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:
>  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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]