Re: Build errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Solved. Having libunwind installed and its include dir visible on my CPATH was the root of everything. (I tried disabling it before, since the build errors suggested something unwind-related, but it turned out I had two installations of libunwind, so it took me much longer to figure out.)


Yang Zhang wrote:
I tried as another user, and it got farther - enough that a make install installed everything I needed. The build fails instead instead at:

$ make -s
...
Adding multilib support to Makefile in ../../.././libiberty
with_multisubdir=32
../.././libiberty/regex.c:51:25: error: sys/types.h: No such file or directory ../.././libiberty/regex.c:130: warning: function declaration isn't a prototype ../.././libiberty/regex.c:130: warning: conflicting types for built-in function 'malloc' ../.././libiberty/regex.c:131: warning: function declaration isn't a prototype
...
[many more errors]
...

So something is screwed up with my first user's environment. What might have been configured differently, causing the failure to occur in the unwind stuff rather than later in libiberty?


Brian Dessent wrote:
Yang Zhang wrote:

In file included from ../.././gcc/unwind-dw2.c:40:
../.././gcc/unwind-pe.h:103: error: expected '=', ',', ';', 'asm' or
'__attrib       ute__' before 'base_of_encoded_value'
../.././gcc/unwind-pe.h:133: error: expected declaration specifiers or
'...' before '_Unwind_Word'
../.././gcc/unwind-pe.h: In function 'read_uleb128':
../.././gcc/unwind-pe.h:137: error: '_Unwind_Word' undeclared (first use
in this function)
../.././gcc/unwind-pe.h:137: error: (Each undeclared identifier is
...
./configure --target=x86_64-jos-linux --prefix=/opt/gcc-4.1.2-jos-linux
--disable-nls --without-headers --with-newlib --disable-threads
--disable-shared --disable-libmudflap --disable-libssp

make && make install

Why are you using --without-headers with a linux target?  The docs say:

--without-headers

Tells GCC not use any target headers from a libc when building a cross compiler. When crossing to GNU/Linux, you need the headers so GCC can build the exception handling for libgcc.

So that is why your build fails.

The real question is what are you trying to do -- what libc are you
really using?  Is your target actually using newlib and not glibc?  Do
you really mean to build a crosscompiler and not a native?

Yeah, I believe I'm trying to build a cross compiler.


Brian

Thanks

Yang



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux