public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Binutils 2.17: configure in libiberty does not find stdlib.h -> build failure
@ 2007-04-14 20:32 Martin Haupt
  2007-04-16  7:44 ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Haupt @ 2007-04-14 20:32 UTC (permalink / raw)
  To: binutils

I am currently trying to build diy-linux with a crosstool compiler on a  
lfs 6.2 live system (64bit).
But the first binutils build fails in libibery/cplus-dem.c because  
stdlib.h is missing (it's there and the compiler finds it). I looked  
through the logs and found out that configure in the libiberty directory  
is the only configure which is not finding stdlib.h (and other standard  
includes)!

Now there is a strange spot in the config.log:

configure:3691: checking for stdlib.h
configure:3704: x86_64-unknown-linux-gnu-gcc -Wl,-dynamic-linker  
-Wl,/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2  
-E  conftest.c
x86_64-unknown-linux-gnu-gcc: -dynamic-linker: linker input file unused  
because linking not done
x86_64-unknown-linux-gnu-gcc:  
/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2:  
linker input file unused because linking not done
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

You see that there is a return value of 0 which should be fine imho.  
configure claims now there would be no such file. I think configure is  
doing wrong here.
I hope somebody can help me.

Martin Haupt


System:
Lfs live cd 6.2-5
Kernel: 2.6.16.38-64bit
GCC: 4.1.1 (crosstool)
Binutils: 2.16.1 (crosstool)
Glibc: 2.3.6 (with tls) (crosstool)
Target: x86_64-unknown-linux-gnu
Binutils: 2.17
DIY: CVS Release April 10th, 2007
$CC: "x86_64-unknown-linux-gnu-gcc -Wl,-dynamic-linker  
-Wl,/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2"

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Binutils 2.17: configure in libiberty does not find stdlib.h -> build failure
  2007-04-14 20:32 Binutils 2.17: configure in libiberty does not find stdlib.h -> build failure Martin Haupt
@ 2007-04-16  7:44 ` Alan Modra
  2007-04-16 21:07   ` Martin Haupt
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2007-04-16  7:44 UTC (permalink / raw)
  To: Martin Haupt; +Cc: binutils

On Sat, Apr 14, 2007 at 09:30:51PM +0200, Martin Haupt wrote:
> I am currently trying to build diy-linux with a crosstool compiler on a  
> lfs 6.2 live system (64bit).
> But the first binutils build fails in libibery/cplus-dem.c because  
> stdlib.h is missing (it's there and the compiler finds it). I looked  
> through the logs and found out that configure in the libiberty directory  
> is the only configure which is not finding stdlib.h (and other standard  
> includes)!

That will be because Daniel made libiberty/configure.ac invoke
AC_PROG_CPP_WERROR, thus turning cpp warnings into errors.
See http://sourceware.org/ml/binutils/2003-09/msg00416.html
configure in other dirs doesn't do this.

> Now there is a strange spot in the config.log:
> 
> configure:3691: checking for stdlib.h
> configure:3704: x86_64-unknown-linux-gnu-gcc -Wl,-dynamic-linker  
> -Wl,/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2  
> -E  conftest.c
> x86_64-unknown-linux-gnu-gcc: -dynamic-linker: linker input file unused  
> because linking not done
> x86_64-unknown-linux-gnu-gcc:  
> /cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2:  
> linker input file unused because linking not done
> configure:3710: $? = 0

It is indeed strange that you have linker options being passed to your
cpp.  How are you configuring?  Do you specify CPP or CPPFLAGS,
perhaps via your environment?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Binutils 2.17: configure in libiberty does not find stdlib.h -> build failure
  2007-04-16  7:44 ` Alan Modra
@ 2007-04-16 21:07   ` Martin Haupt
  0 siblings, 0 replies; 3+ messages in thread
From: Martin Haupt @ 2007-04-16 21:07 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

On Mon, 16 Apr 2007 06:42:58 +0200, Alan Modra <amodra@bigpond.net.au>  
wrote:

> That will be because Daniel made libiberty/configure.ac invoke
> AC_PROG_CPP_WERROR, thus turning cpp warnings into errors.
> See http://sourceware.org/ml/binutils/2003-09/msg00416.html
> configure in other dirs doesn't do this.

I have to excuse myself because I did not really point to the real error  
message I get from gcc(!). Gcc fails to compile  
toplevel/libiberty/cplus-dem.c in line 55 because of conflicting types for  
malloc (which implies that there really is a stdlib.h). Here is the error  
message:

if [ x"" != x ]; then \
	  x86_64-unknown-linux-gnu-gcc -Wl,-dynamic-linker  
-Wl,/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2  
-c -DHAVE_CONFIG_H -pipe -O3 -march=athlon64  -I.  
-I../../binutils-2.17/libiberty/../include  -W -Wall -pedantic  
-Wwrite-strings -Wstrict-prototypes -Wc++-compat   
../../binutils-2.17/libiberty/cplus-dem.c -o pic/cplus-dem.o; \
	else true; fi
x86_64-unknown-linux-gnu-gcc -Wl,-dynamic-linker  
-Wl,/cross-tools/x86_64-unknown-linux-gnu/sys-root/lib64/ld-linux-x86-64.so.2  
-c -DHAVE_CONFIG_H -pipe -O3 -march=athlon64  -I.  
-I../../binutils-2.17/libiberty/../include  -W -Wall -pedantic  
-Wwrite-strings -Wstrict-prototypes -Wc++-compat  
../../binutils-2.17/libiberty/cplus-dem.c -o cplus-dem.o
../../binutils-2.17/libiberty/cplus-dem.c:55: warning: function  
declaration isn't a prototype
../../binutils-2.17/libiberty/cplus-dem.c:55: error: conflicting types for  
'malloc'
../../binutils-2.17/libiberty/cplus-dem.c:56: warning: function  
declaration isn't a prototype
../../binutils-2.17/libiberty/cplus-dem.c: In function  
'code_for_qualifier':
../../binutils-2.17/libiberty/cplus-dem.c:582: warning: implicit  
declaration of function 'abort'
../../binutils-2.17/libiberty/cplus-dem.c:582: warning: incompatible  
implicit declaration of built-in function 'abort'
../../binutils-2.17/libiberty/cplus-dem.c: In function 'qualifier_string':
../../binutils-2.17/libiberty/cplus-dem.c:622: warning: incompatible  
implicit declaration of built-in function 'abort'
../../binutils-2.17/libiberty/cplus-dem.c: In function 'squangle_mop_up':
../../binutils-2.17/libiberty/cplus-dem.c:1082: warning: implicit  
declaration of function 'free'
../../binutils-2.17/libiberty/cplus-dem.c: In function  
'demangle_qualified':
../../binutils-2.17/libiberty/cplus-dem.c:3177: warning: implicit  
declaration of function 'atoi'
make[2]: *** [cplus-dem.o] Error 1
make[2]: Leaving directory  
`/mnt/lfs/temptools/src/binutils-build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/mnt/lfs/temptools/src/binutils-build'
make: *** [all] Error 2

> It is indeed strange that you have linker options being passed to your
> cpp.  How are you configuring?  Do you specify CPP or CPPFLAGS,
> perhaps via your environment?

I have only specified the following flags: LD_LIBRARY_PATH, CC, CXX, LD,  
AR, AS, RANLIB. I appended the linker path to CC and CXX, so that I can  
run 64bit executables without having them statically linked.
See here:
http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&dc=DB520&uid=swg21242495&loc=en_US&cs=UTF-8&lang=en&rss=ct2239other
LD_LIBRARY_PATH points to the 64bit libs. I have not set CPP and CPPFLAGS.
Your question about CPP and CPPFLAGS made me curious about why I had not  
set them. So CPP also points to crosstool-cpp. Binutils compiles now.  
Thank you for your help!

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-04-16 14:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-14 20:32 Binutils 2.17: configure in libiberty does not find stdlib.h -> build failure Martin Haupt
2007-04-16  7:44 ` Alan Modra
2007-04-16 21:07   ` Martin Haupt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).