Deepen Mantri wrote:
Hi,
I am building the C/C++ GCC toolchain for i386 target on x86/Linux
platform.
"i386 target"? What on earth is this? "i386-aout", "i386-coff",
"i386-elf", "i386-djgpp2.3",
"i386-linux-gnulibc1", "i386-freebsd", "i386-cygwin",.... Do you really
think all these being
"just the same 'i386' target"?
The native gcc version is "gcc (GCC) 3.2 20020903 (Red Hat
Linux 8.0 3.2-7)" and the version of the sources are:
GCC : gcc-4.3-20070302
Binutils : binutils-070204
Newlib : newlib-1.15.0
To enable libmudflap library, I am passing the "--enable-libmudflap"
option in the gcc configure script
And the other "configure options" were? Was the "--with-newlib" used
at all although really
using newlib as the C library?
But I get the following error
during final gcc building:
"configure error: none of the known symbol names works
[configure-target-libmudflap] Error 1"
What can be reason for this failure? Are some additional options
required to be added in the configure script to enable the libmudflap
library?
When trying to produce ANY "extra libraries" after the "gcc" for GCC
itself, the '--with-newlib' (and
then really using newlib as the target C library) is obligatory if not
having that prebuilt target C library
available when configuring those extra libraries (and when doing that,
the configury trying to investigate
the base target C library)!
So basically if you gave that obligatory '--with-newlib', the
'libmudflap' configury SHOULD have understood
that it cannot investigate the unexisting "prebuilt newlib for the
target" ! But maybe you added the 'newlib'
and 'libgloss' subdirs into the main 'gcc-4.3' sources and then built
newlib BEFORE going to configure
anything "extra"?
Okeydokey, a quick search in the 'libmudflap/configure' for the "none
of the known symbol names works"
and then seeing what causes this error msg, would have told that the
"program entry point" name, '_start' or
'__start' was investigated there... This is usually in the 'crt0.o'
startup :
Dell:/usr/local/i386-elf/lib # nm crt0.o
00000000 T _start <-------- !!!
00000024 D environ
0000002a t eprol
U errno
U exit
00000000 b fd
00000000 t gcc2_compiled.
U main
00000000 d sccsid
So maybe the configure tried to link some dummy stub program... If so,
there is a bug and the workaround
is to produce newlib between GCC and the "extra libraries", like :
make all-gcc
make install-gcc
<build and install newlib with the installed GCC>
make all
What the libmudflap configury should have done, is to provide the right
'*start' symbol name but in the 'i386-coff'
case this could have been '__start' when with 'i386-elf' it is '_start'
as was seen previously....
Maybe you should remove that "--enable-libmudflap" and do :
make all
make install
<build and install newlib with the installed GCC>
make configure-target-libmudflap
make all-target-libmudflap
