From: greyham@research.canon.com.au (Graham Stoney)
To: dmalek@jlc.net (Dan Malek)
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: GLIBC wont compile for MPC860
Date: Mon, 6 Sep 1999 11:15:06 +1000 (EST) [thread overview]
Message-ID: <19990906011506.87848730@elph.research.canon.com.au> (raw)
In-Reply-To: <37CFEDCD.ACA47B7C@jlc.net> from "Dan Malek" at Sep 3, 99 11:48:29 am
Dan Malek writes:
> Some of us actually creating embedded applications in this space
> are a little concerned with the size of glibc2, and I suspect
> we will be doing some major hacking to fit some of the smaller
> environments.
I think newlib would be a promising candidate given its emphasis on small size,
although the current version needs some porting work to run under Linux/PPC.
My application also needs threads, but I'm hoping I might be able to drop
LinuxThreads from glibc into newlib without too much bloat. For a first cut
though, I'll just drop lots of RAM in and link statically against glibc-2.1.2.
> > ..... but this
> > also means that I don't know what you should do to build a compiler that
> > generates 860 code by default and also is capable of generate code for
> > other CPUs.
>
> I don't know if this is important. Most of us are used to using the
> proper flags, want to use the same compiler on our Linux/PPC Macs
> as is used for the other processors. With the new 82xx stuff
> coming up now, a different set of flags are necessary, and the
> compiler supports it just fine.
Sure, but I'm cross compiling from an Intel box and it would be nice to be able
to configure a gcc --with-cpu=860 and have it imply -msoft-float, -D_SOFT_FLOAT
and whatever else is needed when building glibc/newlib etc.
> > I like the former solution. Having the compiler keep track of what
> > line sizes different CPUs have is good, but forcing other user-land
> > code to know this isn't nice IMHO.
>
> Well, see the comment below. There is some merit to using a
> standard binary distribution on all processors.
Sure; I agree 100%. The tiny extra bloat involved to retain binary
compatibility seems worth it even for an embedded app.
> In general, for all of the real world products I have done
> using Linux/PPC and 8xx, I use the old libc-1.99 and static
> linking. Don't forget about trying that, as it could result
> in the smallest (and fastest) executables.
Any chance you could put your libc-1.99 (or a pointer to it) up at
ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/ ?
Thanks,
Graham
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-09-06 1:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-30 1:12 GLIBC wont compile for MPC860 Brendan Simon
1999-08-30 18:26 ` Scott Wood
1999-08-31 0:39 ` Graham Stoney
1999-09-01 20:27 ` Scott Wood
1999-09-01 21:47 ` David Edelsohn
1999-09-02 12:27 ` Marcus Sundberg
1999-09-03 2:15 ` Graham Stoney
1999-09-03 2:40 ` Michael Meissner
1999-09-03 12:18 ` Marcus Sundberg
1999-09-03 15:48 ` Dan Malek
1999-09-03 15:53 ` Grant Erickson
1999-09-06 1:15 ` Graham Stoney [this message]
1999-09-06 5:57 ` Dan Malek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990906011506.87848730@elph.research.canon.com.au \
--to=greyham@research.canon.com.au \
--cc=dmalek@jlc.net \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).