similar to: [PATCH] configure: Don't define _FORTIFY_SOURCE.

The embedded copy of ocaml-augeas does Val_int(-1), which in turns triggers warnings in newer GCC versions about "left shift of negative value". The issue actually lies in the OCaml headers (mlvalues.h in particular), and it was fixed in newer OCaml versions. Since the code is actually correct, disable -Wshift-negative-value with -Wno-shift-negative-value (checking whether the compiler

SSIA Martin Kletzander (2): Don't redefine _FORTIFY_SOURCE Get rid of gnulib error bootstrap | 2 +- configure.ac | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 1.8.3.2

On Tue, Dec 27, 2016 at 8:30 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner < > carstenmattner at gmail.com> wrote: > >> > >> After figuring out the fault in the configuration step and

On Tue, Dec 27, 2016 at 8:49 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Tue, Dec 27, 2016 at 8:30 AM, Carsten Mattner <carstenmattner at gmail.com > > wrote: > >> On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> > >> > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner <

On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com> wrote: > > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> After figuring out the fault in the configuration step and rebuilding, >> and then rebuilding again by forcing it with `ninja -k 16`, I managed to >> build everything but 12 ninja

ibm68p0:/home/b08chm/m4/m4-1.4.14] # oslevel -s 6100-04-02-1007 [ibm68p0:/home/b08chm/m4/m4-1.4.14] # $ make make all-recursive Making all in . Target "all-am" is up to date. Making all in examples Target "all" is up to date. Making all in lib rm -f alloca.h-t alloca.h && { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; cat

--- configure.ac | 23 ++------------------ m4/ax_add_fortify_source.m4 | 53 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 21 deletions(-) create mode 100644 m4/ax_add_fortify_source.m4 diff --git a/configure.ac b/configure.ac index 8576cae5..c5b63370 100644 --- a/configure.ac +++ b/configure.ac @@ -393,9 +393,7 @@ fi dnl If debugging is

Hello, I'd like to ask a couple of things: 1) I would like to move from Debian to CentOS. One thing I will probably miss is the debsecan tool. This utility sends me a mail whenever there is a change regarding the vulnerabilities' status on my system. It lists new ones, resolved ones and current ones. Is there anything similar for CentOS? 2) I read that RHEL packages are compiled with

Just to keep others in loop. This issue has been fixed by following additions in Makefile: CPP.Flags += -U_FORTIFY_SOURCE CPP.Flags += -D_FORTIFY_SOURCE=0 Thanks, Ahmad From: ahmad.hassan at sap.com Sent: 07 January 2013 19:52 To: llvmdev at cs.uiuc.edu Subject: _FORTIFY_SOURCE warnings Hi All, I have modified the Makefile inside llvm/tools/clang and added the following flag: CPP.Flags +=

Two issues re R on AIX that came up in recent email exchange with Dan Million <lio@hpss1.ccs.ornl.gov>: * We currently use the Autoconf AC_AIX macro which essentially 'defines' _ALL_SOURCE on AIX. According to Dan, on AIX one ends up with #define _ALL_SOURCE 1 which follows Autoconf's general pattern, but causes a problem as the system headers (unconditionally?) have

Martinez, Javier E wrote: > Hello, > > We have identified functions in LLVM sources using a static code > analyzer which are marked as a “security vulnerability”[1][2]. There has > been work already done to address some of them for Linux (e.g. > snprintf). We are attempting to solve this issue in a comprehensive > fashion across all platforms. Most of the functions identified

Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length array declaration in struct nvfw_hs_load_header_v2 with flex-array member. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link:

Hi All, I have modified the Makefile inside llvm/tools/clang and added the following flag: CPP.Flags += -D_FORTIFY_SOURCE=0 But when I build clang using 'make' then I get lot of warnings like: <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] <built-in>:0:0: note: this is the location of the previous definition Is this expected

These patches first make src/ warning free, and then turn on the strict warning options. 75 0001-build-suppress-an-ignored-write-return-value-warning.patch 38 0002-build-suppress-an-ignored-dup-return-value-warning.patch 27 0003-generator.ml-suppress-signed-unsigned-compare-warnin.patch 48 0004-build-don-t-perform-arithmetic-on-void-pointers.patch 30

On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > After figuring out the fault in the configuration step and rebuilding, > and then rebuilding again by forcing it with `ninja -k 16`, I managed to > build everything but 12 ninja targets. > > I have to sift through them before I can report more, and I don't > don't know if

Just in case there is one person on this list that isn't aware... and so it begins... Craig -------- Forwarded Message -------- > From: nahant-list at redhat.com > Reply-To: nahant-list at redhat.com > To: nahant-list at redhat.com > Subject: Red Hat Enterprise Linux 4 Update 3 Availability Announcement > Date: Tue, 07 Mar 2006 19:32:51 -0500 > > Red Hat is pleased to

On Wed, Mar 07, 2007 at 11:45:13AM +0000, richard wrote: > * configure.ac: Add -D_FORTIFY_SOURCE to AM_CXXFLAGS for GCC > builds. According to glibc CVS support for this was added in > October 2004, but it doesn't seem to be documented very well, > other than in features.h. I'd not come across this before, so I had a quick poke around. It's hardly documented *well* in

Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2)

Hi Rich, Prompted by your "New commands to list devices by UUID and label" patch, I've adjusted it to use gnulib. While just compiling hash.[ch] is probably ok, in general (given the strict requirements of libguestfs) using the C files of a module is usually not an option, since you don't get the benefit of the module's m4 tests or automake snippets. For other modules,

I haven't been tracking dovecot-2.3 until now, but I've just given it a quick run, and there are a few things that may need some attention. Linux x86-64, Gentoo, GCC-7.2.0 Dovecot 2.3 @ commit 32c2612514a404ebc226f32bb88f28d76ceb1db1 Compiled with: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info