This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i386-linux-aout


> >> "i386-linux-aout"? First of all, do I have the correct
> >> target?
> >
> >I think so.
> 
> <removes clown hat for a minute>
> 
>   I'm surprised to hear that there's any such thing as an
>   a.out-based Linux, Linux is not my speciality but I
>   thought all Linux used ELF ?

The Linux I first installed on my PC was a.out only, and
even these days you can compile support for a.out in your
kernel. Some old binary-only executables can still be found
around (althoug the only one I can think of would be Doom,
and even then I'm not sure there isn't an ELF version
somewhere).
However, the fact that everybody has been using ELF almost
exclusively for the last 5 years or so should not prevent
you of building an a.out system.

(That said, for the benefit of the original poster, yeah,
he'd better go for ELF if he has a choice, thanks for
pointing that out David).

> >Wrong. Linux uses Glibc, regardless of where you put your
> >Linux system in the end.
> 
>   That doesn't have to be true.  There is a system called
>   ucLinux that uses it's own cutdown library, similar in
>   nature to newlib.  Search the list archives; it seems
>   that most people find it an easier choice for embedded
>   linux than either the overhead of glibc or the problems
>   in getting newlib to work for Linux.

Sorry, I was being terse. However, I would advice against
uCLibc if you are a newcomer to Linux development. Get your
system running with Glibc, because it's the mainstream,
well-supported method, and then move to uCLibc if you need
to (uCLibc might be easy to use for those that have been
involved in it for months, but I failed miserably to use it
efficiently a couple of times already).

Another alternative is dietlibc, I found it is easier to set
up than uCLibc (it's not as fancy, it only does static
linking) and gives pretty good results.

I guess if you're really into doing small things, you can
even skip using a library at all, and write the entry codes
and syscalls by hand. I'd advise against that tho :-)

> > The equation "newlib==embedded" is
> >wrong; newlib is a C library that throws out most of the
> >bloat of Glibc, and is designed to work with no operating
> >system, so it makes it arguably suitable for embedded.
> 
>   Well it doesn't just throw out bloat: it also throws out
>   a lot of functionality related to dynamic linking and
>   virtual memory IIUIC.  Newlib does have some support for
>   Linux these days according to posts I've seen on this
>   list earlier, but I don't recall anyone actually saying
>   they'd been using it that way on this list.

Oh, that's interesting... I haven't had a look at newlib for
more than a year I think, so things might have happened
meanwhile, you're right! Although again, I'd say get it
working with Glibc and then move to something else when you
have the confidence it works...

Cheers,
Yves




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]