Re: How to enable mudflap with gcc-4.x

[Kai Ruottu <karuottu at mbnet dot fi>]

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