F21 system GCC changed to 4.9.0 prerelease

[Dan Horák]

On Fri, 11 Apr 2014 09:16:33 -0400
Przemek Klosowski <przemek.klosowski at nist.gov> wrote:

> On 04/11/2014 05:10 AM, Jakub Jelinek wrote:
> > On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:
> >> On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:
> >>> On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
> >>>> To investigate runtime rather than compile time
> >>>> issues, please consider using temporarily -fsanitize=undefined
> >>>> and/or -fsanitize=address to look for undefined behavior in the
> >>>> packages you own.
> >>> Which is this in case anyone else was wondering:
> >>>
> >>>    '-fsanitize=address'
> >>>       Enable AddressSanitizer, a fast memory error detector.
> >>> Memory access instructions will be instrumented to detect
> >>> out-of-bounds and use-after-free bugs.  See
> >>>       <http://code.google.com/p/address-sanitizer/> for more
> >>> details. The run-time behavior can be influenced using the
> >>> 'ASAN_OPTIONS' environment variable; see
> >>>       <https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags>
> >>>       for a list of supported options.
> >> Also in case anybody else wonders about gcc failing to recognize
> >> these options, you'll need to add BuildRequires for these: libasan
> >> for -fsanitize=address and libubsan for -fsanitize=undefined (and
> >> similarly for leak and thread sanitizers )
> > Yeah.  But, note that the sanitizers are meant primarily for
> > development, not for production, and especially -fsanitize=thread
> > and to some extent -fsanitize=address aren't completely cheap, so
> > if you do that, please do so temporarily and don't forget to
> > disable it again for production.
> >
> > 	Jakub
> FWIW, some liveCD like e.g. the Electronic Lab started failing because
> 
> libtool-2.4.2-23.fc21.i686 requires gcc = 4.8.2

there is already libtool-2.4.2-24.fc21 that will fix it


		Dan