linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/

  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).