On Sat, 2008-02-16 at 17:50 +0100, Kern Sibbald wrote:
> > There may be another way around this. All of the above is only true when
> > you invoke the %configure macro. Kern, correct me if I'm wrong, but if I
> > replaced %configure with ./configure then wouldn't the configure script
> > set up all
On Mon, 2008-02-11 at 14:14 -0500, Josh Fisher wrote:
> Scott Barninger wrote:
> > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> >
> > Wouldn't the following work, without modifying any other settings?
> >
> > export CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=0"
> >
> > The string would then f
On Mon, 2008-02-11 at 14:14 -0500, Josh Fisher wrote:
> Scott Barninger wrote:
> > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> >
> > Wouldn't the following work, without modifying any other settings?
> >
> > export CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=0"
> >
> > The string would then f
On Mon, 2008-02-11 at 14:14 -0500, Josh Fisher wrote:
>
> Maybe not. The %configure macro defined in /usr/lib/rpm/redhat/macros
> defines CFLAGS="${CFLAGS:-%optflags}" prior to the call to ./configure.
> Thus, if CFLAGS is not already defined, then it sets CFLAGS to defaults
> set by %optflags,
Scott Barninger wrote:
> On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
>
> Wouldn't the following work, without modifying any other settings?
>
> export CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=0"
>
> The string would then first set it to 2 and last reset to zero. And it
> works for all platf
Hello,
For those of you following this discussion, or who may have had problems
building 2.2.8 on systems with glibc 2.7+, I have released
bacula-2.2.8-2 rpm packages. This release includes a new source rpm as
well as Fedora 8 binaries which tested OK for me. This fix should work
for any platform
On Sat, 2008-02-09 at 15:13 +0100, Michael Lausch wrote:
>
> I've a patch ready for the spec file.
>
Thanks. There is a fix I committed to svn earlier, tested on Fedora 8,
and should work on all platforms as glibc 2.7 comes around. I'll publish
a -2 rpm release later today.
--
On Sat, 2008-02-09 at 13:55 +0100, Kern Sibbald wrote:
> On Saturday 09 February 2008 13.26:25 Scott Barninger wrote:
> > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> > > On Friday 08 February 2008 23.16:43 Josh Fisher wrote:
> > > > Kern Sibbald wrote:
> > > > > Please Note the follow
On Sat, 2008-02-09 at 13:55 +0100, Kern Sibbald wrote:
>
> I am assuming that you already have some workaround for building rpms (i.e. a
> way to disable the FORTIFY_SOURCE, and so I am not at the moment considering
> this a critical problem. If this is not the case, please let me know.
>
The
On Sat, 2008-02-09 at 13:55 +0100, Kern Sibbald wrote:
> On Saturday 09 February 2008 13.26:25 Scott Barninger wrote:
> > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> > > On Friday 08 February 2008 23.16:43 Josh Fisher wrote:
> > > > Kern Sibbald wrote:
> > > > > Please Note the followi
On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> On Friday 08 February 2008 23.16:43 Josh Fisher wrote:
> > Kern Sibbald wrote:
> > > Please Note the following quote from the documentation on the
> > > implementation of FORTIFY_SOURCE=2
> > >
> > > With -D_FORTIFY_SOURCE=2 some more che
Kern Sibbald wrote:
> Please Note the following quote from the documentation on the implementation
> of FORTIFY_SOURCE=2
>
> With -D_FORTIFY_SOURCE=2 some more checking is added, but
> some conforming programs might fail.
>
> Bacula is a conforming program (i.e. there is no buffer overrun
Please Note the following quote from the documentation on the implementation
of FORTIFY_SOURCE=2
With -D_FORTIFY_SOURCE=2 some more checking is added, but
some conforming programs might fail.
Bacula is a conforming program (i.e. there is no buffer overrun at that
point).
Best regards,
Hello,
In my opinion, the problem here is that the FORTIFY_SOURCE code is simply
broken and it should be fixed or turned off. Bacula does far more checking
on internal buffers than glibc does, so I see no reason to have
FORTIFY_SOURCE on.
The solution is to turn it off. We don't use FORTIFY_
On Mon, 2008-01-28 at 19:43 -0500, Dan Langille wrote:
> Michael Lausch wrote:
> > The error is due to the new (well ~ core 5) buffer overflow checking
> > implemented by gcc and glibc. _FORTIFY_SOURCE=2 activates it. what
> > happens can be read in detail at
> > http://gcc.gnu.org/ml/gcc-patches
Michael Lausch wrote:
> The error is due to the new (well ~ core 5) buffer overflow checking
> implemented by gcc and glibc. _FORTIFY_SOURCE=2 activates it. what
> happens can be read in detail at
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html. but basically
> the error is a buffer over
OK, I'm a bit over my head here, but this seems like an issue for the
configure script, not packaging. Unless there is a simple env variable I
can set based upon a condition.
On Tue, 2008-01-29 at 00:02 +0100, Michael Lausch wrote:
> The error is due to the new (well ~ core 5) buffer overflow chec
17 matches
Mail list logo
