Experience and comments after building GCC 4.4

Andrew Haley aph@redhat.com
Thu Aug 6 09:34:00 GMT 2009


Hibou57 (Yannick) wrote:

> -- -----------------------------------------------------
> -- sys/types.h
> -- -----------------------------------------------------
> 
> Then, in sysroot, I've put the linux kernel headers, but the build process
> complained about some stdlib.h (which I suppose to be the one of the target
> system) and some others of the like, so I've put some standard C headers in
> there and got troubles with these. There was an error in sys/types.h and
> more exactly with the line “ typedef __caddr_t caddr_t; ” which I've finally
> commented out. I've tried with the MinGW standard C header set, the one from
> another GCC distribution, the one from a Debian server, and it was always
> the same. I suppose there are some trouble with headers inclusions in GCC
> 4.4 sources.

No.  This is an error of yours: in the sysroot must be the headers and the
libraries from the target's libc, not just kernel headers.

> While building libmudflap, it expects a crt1.o, crti.o and crtn.o, and a
> libc.a (static only) in the sysroot/lib directory, otherwise it believes the
> compiler can't build executables. This is strange, beceause this kind of
> target object files is supposed to require a ready compiler to be compiled,
> and this target object if required during the creation of the compiler which
> is supposed to be able to create it .... (loop). I've solved it using some
> I've get from a Debian server (but it is still not a normal behaviour in my
> opinion).

This is the same error: in the sysroot must be the libraries from the target's
libc.

> -- ------------------------------------------------------
> -- libgomp
> -- ------------------------------------------------------
> 
> Same kind of probleme as for libmudflap : it expect a libpthread.a library
> (here as well, only a static library). Same strange behaviour, as it expect
> something which would require the compiler to be ready in order to be
> created (again, a loop).

This is the same error: in the sysroot must be the libraries from the target's
libc.

> -- ------------------------------------------------------
> -- always link static even if -Bdynamic is requested
> -- ------------------------------------------------------
> 
> Finally, the builded environnement is tested with a simple hello-world, and
> it alwyas produce a 500KB program, even with -Bstatic passed to GCC. The
> trouble can only be solved giving the linker the absolute path to a
> libc.so.6, which I once again, copied from a Debian server (there is no
> trouble this time about the libc, beceause I've not builded the libc, which
> cannot be configured at all on my system, anyway, althought I've configured
> it to be hosted on Linux, not Windows). If I only pass a libc.so.6 add an
> -rpath (which I do not like) of an -rpath-link (which I prefer), it solves
> nothing, as well as if I use the LD_RUN_PATH environnement variable (all
> seems to be totally ignored). And by the way, it seems to totally ignor the
> -Bdynamic flags (or it alays falls back to a static library, without even a
> sole warning message).

This is the same error: in the sysroot must be the libraries from the target's
libc.

Andrew.



More information about the Gcc-help mailing list