Hello,
I'm posting in “ GCC help ” instead of “ GCC bugs “, althought I'm talking
about bugs, beceause I'm not a GCC-build-guru. GCC interested people may
note this stuff to try to work on.
-- ----------------------------------------------------------
-- libgcc.map -----------------------------------------------
-- ----------------------------------------------------------
Building GCC with MinGW on Windows, I've noticed that the libgcc cannot be
made dynamic, otherwise in always ends up in trouble with an empty
libgcc.map. I've searched the web about it, it seems if first appears in
2004 on Solaris, it was marked as solved, but I confirm it is still there.
I've used rge --with-gnu{gcc/ld/as}, which did not solved anything. The
target (build for Windows host, targeting Linux, and later, MacOS). Binutils
was in sysroot/bin and were found by configure.
I could only solve it using “ --enable-shared=ada,libada,zlib ”, thus,
disabling to build libgcc as a shared library.
Any way, I've read on the web that it is better to use a static libgcc, to
avoid some troubles. So I may don't mind.
-- -----------------------------------------------------
-- 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.
So missing headers which are not provided by the GCC source (and not
searched in the GCC source directory any way) and trouble with handling of
these headers.
-- ------------------------------------------------------
-- libmudflap
-- ------------------------------------------------------
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).
-- ------------------------------------------------------
-- 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).
-- ------------------------------------------------------
-- 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).
I've solved it adding an “ %R/lib/libc.so.6 ” in the GCC specs file, and it
works, but I do not like it, beceause I will have to add all possible
dynamic libraries there. And surprisingly, if I simply add libc.so.6 in the
specs file, it complains it does not find the file, althought it perfectly
find any static library in the same directory. If I add an “ -R %R ” after
the “ %/lib/libc.so.6 ”, it complains it does not find the file, althought a
file path is specified. If I add a “ -R %R ” before the libc.so.6 (with no
absolute path), it does not complain anymore that it does not find the file,
but still link statically.... very weird stuffs...
--
View this message in context: http://www.nabble.com/Experience-and-comments-after-building-GCC-4.4-tp24839365p24839365.html
Sent from the gcc - Help mailing list archive at Nabble.com.
