[uClibc] Rationale for target naming convention?

Daniel Qarras dqarras at yahoo.com
Tue Nov 2 08:37:57 UTC 2004


Carl, thanks for exceptionally well-written answer,
seems like a FAQ material to me!

--- Carl Miller <chaz at energoncube.net> wrote:

> > I did not find any rationale for target naming
> > convention using for example "arm-linux-uclibc"
> with
> > buildroot when many packages like gdb are trying
> to
> > find something like arm-*-linux? Wouldn't
> > "arm-uclibc-linux" have been much better choice?
> > 
> > Thanks.
> 
> The traditional GNU development tools target tuple
> is
> 
>    CPU architecture - hardware platform/vendor - OS
> 
> Many times, especially in embedded development, the
> middle
> specifier of the tuple is dropped.  This is because
> it is
> not very often relevant to deciding how to build a
> compiler,
> and most embedded targets are specialized hardware
> that are
> too obscure for the tools to know about.  But if you
> watch
> the configure scripts running, they will always
> insert a
> hardware platform/vendor specifier back in if it is
> omitted.
> E.g., "arm-linux" will become "arm-unknown-linux".
> 
> It used to be that for any particular combination of
> CPU
> architecture, hardware vendor or hardware platform,
> and
> operating system, there would only be once choice of
> C
> library.  That is not the case with Linux.  Linux
> can run
> with glibc, uClibc, dietlibc, libc5, or (if you
> really want
> to dig into the dusty archives) libc4.  Thus, for
> Linux
> targets, it's common to extend the target tuple to
> four
> fields:
> 
>    CPU architecture - platform/vendor - OS - C
> library
> 
> However, some older versions of tools don't
> recognize the
> fourth field properly, and it's only recently that
> patches
> are becoming common to make the tools respond
> properly to
> C library fields other than "-gnu" (referring to
> glibc).
> 
> Thus, "arm-linux-uclibc" is correct because the C
> library
> must be specified last, in the fourth field, and
> only three
> fields are shown because the hardware
> platform/vendor is
> being omitted as moot.  Recent tools should
> canonicalize
> this properly to "arm-unknown-linux-uclibc".
> 
> "arm-uclibc-linux" is not correct because it
> indicates that
> either the name of your target hardware, or the name
> of the
> vendor who designed/manufactured your target
> hardware is
> "uclibc", and since you have not specified a C
> library in
> the fourth field, the default library will be
> assumed (which
> is glibc for Linux).
> 
> 
>                          ------Carl
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 




More information about the uClibc mailing list