HEADSUP: toolchain modifications required for built-in SSP
Mon Dec 4 12:01:00 GMT 2017
On Dec 4 08:32, Sebastian Huber wrote:
> It would be nice to have a snapshot before the next release to test this. Is
> the next release 3.0.0 (due to the 64-bit time_t) or 2.6.0?
> On 30/11/17 11:41, Yaakov Selkowitz wrote:
> > gcc8-ssp-newlib.patch
> > 2017-11-29 Yaakov Selkowitz<email@example.com>
> > gcc/
> > * configure.ac (gcc_cv_libc_provides_ssp): Define as yes
> > on Newlib-based targets if new builtin SSP support is present.
> > * configure: Regenerate.
> > Index: gcc/configure
> > ===================================================================
> > --- gcc/configure (revision 255250)
> > +++ gcc/configure (working copy)
> > @@ -29100,6 +29100,12 @@
> > fi
> > ;;
> > + *-*-cygwin* | *-*-rtems* | *-*-eabi* | *-*-elf* | mmix-knuth-mmixware)
> Instead of this target enumeration, could we not use an $EGREP approach
> similar to some other libc variants?
Can you make up an example?
> > + # This is a recent addition to Newlib/Cygwin/RTEMS
> The "recent addition" is probably no longer that recent in one or two years.
> Maybe we should use a version or date here, e.g. since Newlib snapshot XYZ.
Good point. Date should suffice, I think,
> > + if test -f $target_header_dir/ssp/ssp.h; then
> > + gcc_cv_libc_provides_ssp=yes
> > + fi
> > + ;;
> > *) gcc_cv_libc_provides_ssp=no ;;
> > esac
> > fi
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Newlib