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.
