Re: crosstool and uClibc

[Kai Ruottu <karuottu at mbnet dot fi>]

Dan Kegel kirjoitti:

> Yann E. MORIN wrote:
> > /users/e800-uclibc/lib/gcc/armv5l-xscale-linux-gnu/3.4.3/../../../../armv5l-xscale-linux-gnu/lib/libgcc_s.so: 
> > undefined reference to `dl_iterate_phdr'
> > collect2: ld returned 1 exit status
>
> Hrm.  Maybe the following is related?
>
> http://uclibc.org/lists/uclibc/2004-January/007943.html
> http://uclibc.org/lists/uclibc/2004-January/007944.html

 Definitely these seemed to be "related"...

 When looking at the current "stable" GCC, the gcc-3.4,
sources, the only "support" for uCLinux seemed to be for
ARM and m68k. And at least the ARM support was badly
broken, the 'gcc/config/arm/uclinux-elf.h' :

------------------------- clip -------------------------
/* Definitions for ARM running ucLinux using ELF
   Copyright (C) 1999, 2001 Free Software Foundation, Inc.
   Contributed by Philip Blundell <pb@nexus.co.uk>

   This file is part of GCC.

   GCC is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published
   by the Free Software Foundation; either version 2, or (at your
   option) any later version.

   GCC is distributed in the hope that it will be useful, but WITHOUT
   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
   License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING.  If not, write to
   the Free Software Foundation, 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/* We don't want a PLT.  */
#undef  NEED_PLT_RELOC
#define NEED_PLT_RELOC 0

#undef  TARGET_VERSION
#define TARGET_VERSION fputs (" (ARM/ELF ucLinux)", stderr);

#undef  TARGET_DEFAULT
#define TARGET_DEFAULT (ARM_FLAG_APCS_32 | ARM_FLAG_MMU_TRAPS | 
ARM_FLAG_SINGLE_PIC_BASE)
------------------------- clip -------------------------

which is the last config header read for the 'arm*-uclinux' target,
doesn't redefine the wrong settings in the earlier included config
headers like this in the 'gcc/config/arm/linux-elf.h' :

------------------------- clip -------------------------
#undef  LINK_SPEC
#define LINK_SPEC "%{h*} %{version:-v} \
   %{b} %{Wl,*:%*} \
   %{static:-Bstatic} \
   %{shared:-shared} \
   %{symbolic:-Bsymbolic} \
   %{rdynamic:-export-dynamic} \
   %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2} \
   -X \
   %{mbig-endian:-EB}" \
   SUBTARGET_EXTRA_LINK_SPEC
------------------------- clip -------------------------

because it seems to be from 2001 when uCLinux didn't use shared
libs and generally was still quite "under construction"....

 The '/lib/ld-linux.so.2' doesn't belong to current uCLinux !!!

 So nobody has cared to fix anything in those FSF sources what comes
to the uCLinux support?  Not even the 'mipsel-uclinux' target used
in those well-known Linksys/Cisco, Buffalo etc. WiFi-routers was
implemented... Generally the Broadcomm tools coming with some '4.0'
firmware packet looked like being a horrible mess with a 'mipsel-linux'
toolchain used also as the toolchain for 'mipsel-uclinux'. Is the
current know-how in those companies really this low that they cannot
even fix those simple config headers and then get a "real" '*-uclinux'
target toolchain instead of a mess?  Or is this mess somehow what
they really want?

 My thought is that if not a newbie, then at least a novice could
be capable to edit the config-headers chain for some uCLinux like
for the ARM one defined in the target template in 'gcc/config.gcc' :

------------------------- clip -------------------------
arm*-*-uclinux*)		# ARM ucLinux
	tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
	tmake_file=arm/t-arm-elf
	;;
------------------------- clip -------------------------

 The 'tm_file' headers chain terminates in the 'arm/uclinux-elf.h',
and this should fix everything which was wrong for uCLinux in the
earlier ones...

 Someone who has possibilities to get paid, like those Broadcomm
people, could have sent patches to the also paid GCC official
developers (or doesn't GNU/FSF get any money any more?) who then
have access to the GCC sources. It seems that some companies really
use uCLinux in their products and should get money when selling them
but don't pay back in any way, not even by getting the GNU/FSF sources
fixed for uCLinux !

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