More sh-linux-gnu problems (was : newbie questions remain regarding crosstool...)

["Kai Ruottu" <karuottu at mbnet dot fi>]

"Kai Ruottu" <karuottu@mbnet.fi> wrote:

>  My PC is just trying to build glibc-2.3.2 for 'sh-linux-gnu' (with the SH3 defaults).
> The build stopped with 'stdio-common/sscanf.c', this function being a builtin with
> gcc-3.3.1 for SH, but a hack via wrapping the function with '#ifndef __sh__' and
> '#endif' seemed to allow the build to continue...

 Another 'bug' was found in the linux-2.4.22 kernel headers. The header
'include/linux/types.h' defines the 'struct ustat' and the glibc-2.3.2 sources
also define this in 'sysdeps/generic/bits/ustat.h'. The latter has a wrapper
to make sure that it will not be tried to be redefined, but the '<linux/types.h>'
doesn't use the same needed flag. So adding the same wrapper there:

--------------------------------- clip ----------------------------------------------------
--- 126,139 ----
   * Below are truly Linux-specific types that should never collide with
   * any application/library that wants linux/types.h.
   */

+ #ifndef _STRUCT_USTAT
+ #define _STRUCT_USTAT
  struct ustat {
        __kernel_daddr_t        f_tfree;
        __kernel_ino_t          f_tinode;
        char                    f_fname[6];
        char                    f_fpack[6];
  };
+ #endif

  #endif /* _LINUX_TYPES_H */
--------------------------------- clip ----------------------------------------------------

could be the right way to fix this...

 Furthermore my 'as' from Linux binutils-2.13.90.0.16 crashed with some 'rtld-' routine
in '$build/elf' and while the update to the recent 2.14.90.0.6 helped for a while, the used
C compiler itself, gcc-3.3.1 for 'sh-linux-gnu', crashed quite soon with:

--------------------------------- clip ----------------------------------------------------
sh-linux-gnu-gcc-3.3 ../sysdeps/unix/sysv/linux/_exit.c -c -std=gnu99 -Os -Wall
<snip>
 -o /home1/src/glibc-2.3.2/build/posix/rtld-_exit.os
../sysdeps/unix/sysv/linux/_exit.c: In function `_exit':
../sysdeps/unix/sysv/linux/_exit.c:44: internal compiler error: Segmentation fault
--------------------------------- clip ----------------------------------------------------

 Maybe using another optimization instead of the '-Os' could have helped...  Or
the bugfixes coming with the new gcc-3.3.2...

 So although there are 'maintainers' for these FSF things, just taking the current
released (so expected to be thoroughly tested, not any experimental beta) sources,
doesn't necessarily lead to any big success... Generally this kind of approach is not
the best although one could expect the newest ones being most bug-free.

 Maintainers usually work with 0-10 years old released stuff when developers try to
add those new fancy 'features', a'la MS and don't care about fixing any existing bugs...
Maybe the real 'maintainers' are outside the FSF-community.

 Spying what others have used in their current working production-level
'*-linux-gnu' toolchains could be much better. If one needs the tools for some serious
purposes, not only for toying with them, or only to see whether one can build them, then
leaving even the toying away, as was with my case, then getting the critical parts like
the C libraries could be sane...  But even this bright idea can fail miserably... 

 When the 'sh-linux-gnu' target requires four separate glibcs, for 'm3' (the default), 'mb',
'm4' and 'mb/m4', it sounded sane that building all the missing 3 glibcs (I had built
the default one from glibc-2.2.5 sources) wouldn't be wise and just downloading the
current released production (thoroughly tested?) glibcs from the Linux/SH gurus would
be the easy way... I did this with some glibc-2.2.5-something for them all... But when
downloaded and installed, I found them being spoiled with stripping them without the
usual '--strip-debug':

/home2/usr/local/sh-linux-gnu/lib # file libc-2.2.5.so
libc-2.2.5.so: ELF 32-bit LSB shared object, Hitachi SH, version 1, stripped
/home2/usr/local/sh-linux-gnu/lib # ../bin/nm libc-2.2.5.so
../bin/nm: libc-2.2.5.so: no symbols
/home2/usr/local/sh-linux-gnu/lib # ../bin/nm m4/libc-2.2.5.so
../bin/nm: m4/libc-2.2.5.so: no symbols
/home2/usr/local/sh-linux-gnu/lib # ../bin/nm mb/libc-2.2.5.so
../bin/nm: mb/libc-2.2.5.so: no symbols
/home2/usr/local/sh-linux-gnu/lib # ../bin/nm mb/m4/libc-2.2.5.so
../bin/nm: mb/m4/libc-2.2.5.so: no symbols
/home2/usr/local/sh-linux-gnu/lib # l libc-2.2.5.so
-rwxr-xr-x    1 root     root      1126964 Oct  7  2002 libc-2.2.5.so
/home2/usr/local/sh-linux-gnu/lib # l m4/libc-2.2.5.so
-rwxr-xr-x    1 10001    10001     1251336 Oct  7  2002 m4/libc-2.2.5.so
/home2/usr/local/sh-linux-gnu/lib # l mb/libc-2.2.5.so
-rwxr-xr-x    1 10001    10001     1124760 Oct  7  2002 mb/libc-2.2.5.so
/home2/usr/local/sh-linux-gnu/lib # l mb/m4/libc-2.2.5.so
-rwxr-xr-x    1 10001    10001     1249612 Oct  7  2002 mb/m4/libc-2.2.5.so

 Why these kind of things can appear on the net?  As seen my download happened
some time ago and maybe there are now non-spoiled prebuilt tested glibcs for the
sh-linux-gnu target.  Maybe some guru built these but then left the easy task of
strip'ing and packing to some newbie...  Really frustrating and too hard when the
'sh-linux-gnu' target should be both supported and maintained.

Cheers, Kai

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com