linux build problem

Since yesterday I've been getting the error below when building llvm-gcc on Ubuntu Hardy on x86. For some reason, several instances of autoconf are getting confused and failing to detect a stdlib.h.

John

/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/ -B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c -DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I. -I../../libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o cplus-dem.o
no
checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning: function declaration isn’t a prototype
../../libiberty/cplus-dem.c:55: error: conflicting types for ‘malloc’

I'll need some more information than this. I don't have a Linux box, so I can't tell. Do you have a .i file? How is autoconf being confused? What does config.log say about it?

-bw

Since yesterday I've been getting the error below when building llvm-
gcc
on Ubuntu Hardy on x86. For some reason, several instances of
autoconf
are getting confused and failing to detect a stdlib.h.

John

/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc
-B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/
-B/home/regehr/z/tmp/llvm-gcc-r62547-install/i686-pc-linux-gnu/bin/ -c
-DHAVE_CONFIG_H -O2 -g -fomit-frame-pointer -I.
-I../../libiberty/../include -W -Wall -pedantic -Wwrite-strings
-Wstrict-prototypes -Wc++-compat ../../libiberty/cplus-dem.c -o
cplus-dem.o
no
checking for ldfcn.h... ../../libiberty/cplus-dem.c:55: warning:
function declaration isn’t a prototype
../../libiberty/cplus-dem.c:55: error: conflicting types for ‘malloc’
_______________________________________________
    
I'll need some more information than this. I don't have a Linux box,
so I can't tell. Do you have a .i file? How is autoconf being
confused? What does config.log say about it?

I've seen this failure on my nightly builder too (SVN r62521), it is
related to the -Wformat-security changes,
apparently libiberty's configure considers warnings as failures:

configure:3691: checking for stdlib.h
configure:3704: /home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/xgcc
-B/home/edwin/llvm-bootstrap/llvm-obj/./prev-gcc/
-B/home/edwin/llvm-bootstrap/llvm-obj/../install/x86_64-unknown-linux-gnu/bin/
-E conftest.c

cc1: warning: -Wformat-security ignored without -Wformat

configure:3710: $? = 0
configure: failed program was:

/* confdefs.h. */

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
/* end confdefs.h. */
#include <stdlib.h>

configure:3731: result: no

Best regards,
--Edwin

I recently put in a "hack" that would default -Wformat-security to on when -Wformat is on, and off when off. Is it still breaking? If so, I'm going to hijack a coworker's Linux box and see if I can get to the bottom of this.

As always, I'm sorry for the breakage. These merges are annoying, but important for a variety of reasons. This merge, for instance, got the Fortran FE to compile and run the test suite. :slight_smile: I'll fix the build problems before the code freeze on the 21st.

-bw

Hi Bill,

I recently put in a "hack" that would default -Wformat-security to on
when -Wformat is on, and off when off. Is it still breaking?

yes, I still see lots of
  "cc1: warning: -Wformat-security ignored without -Wformat"

If so,
I'm going to hijack a coworker's Linux box and see if I can get to the
bottom of this.

Thanks!

Ciao,

Duncan.

I recently put in a "hack" that would default -Wformat-security to on
when -Wformat is on, and off when off. Is it still breaking? If so,
I'm going to hijack a coworker's Linux box and see if I can get to the
bottom of this.

As always, I'm sorry for the breakage. These merges are annoying, but
important for a variety of reasons. This merge, for instance, got the
Fortran FE to compile and run the test suite. :slight_smile: I'll fix the build
problems before the code freeze on the 21st.

I just got this failure :frowning:

Trying to investigate a bit.

-bw

Cheers,

As always, I'm sorry for the breakage. These merges are annoying, but
important for a variety of reasons. This merge, for instance, got the
Fortran FE to compile and run the test suite. :slight_smile: I'll fix the build
problems before the code freeze on the 21st.

np. Can you try the attached patch? The idea is to have the driver
(gcc) handle the darwin/non-darwin issues and the compiler (cc1) just
uses the arguments passed to it.

Fixes the build on linux.

-bw

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Cheers,

format2.patch (4 KB)

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details.

THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is.

Thanks,

John

I'm away from my Linux machines, if this hasn't been resolved by tonight
I'll send more details.

THe problem in cplus-dem.c is that CPP is conditionally including code that
comes when HAVE_STDLIB is not defined, including an alternate protptype for
malloc() that conflicts with the existing one. This is just what causes the
error I sent-- no idea what the root cause is.

I have posted a patch that fixes it for me. Waiting for someone to
test it on Darwin.

Thanks,

John

Cheers,

Fixes the build on linux.

I can confirm that this fixes the build on
x86-64 linux.

Ciao,

Duncan.

I went ahead and applied this patch. Thanks, Rafael!

-bw

I do have a concern that this might have regressed the Fortran FE.
Could you (or someone who runs it) test this?

-bw

I do have a concern that this might have regressed the Fortran FE.
Could you (or someone who runs it) test this?

I noticed my patch was applied and then reverted. I am curious, why
was it a problem for the Fortran FE?

-bw

Cheers,

Reverted, but with a better fix. :slight_smile: I wanted to keep it more in sync
with Apple's GCC. The Fortran FE has had a lot of troubles with these
warnings. Your patch reverted things back to how they were before the
merge, i.e. to the way that would cause the warnings to occur. I don't
know why, because the warning mechanism of GCC is opaque to me.

-bw

Works fine for me now BTW.

Thanks!

John