| View previous topic :: View next topic |
| Author |
Message |
Sanguinary
n00b
Joined: 17 Oct 2004
Posts: 16
|
 Posted: Thu Jul 14, 2011 1:25 am Post subject: Cobalt / mipsel4 and uClibc? |
 |
|
I'm thinking about reviving a Cobalt Qube 2. I've used Gentoo on these before--I even saw some of my old posts from years ago in my searches before posting this. I have a reasonably recent stage3 tarball from Redhatter's website, but what I'd really like to do this go around is use uClibc. My problem is that I can't find any Gentoo uClibc / mipsel4 stage tarballs, let alone a stage 3.
From some bug reports made by Redhatter about uClibc (re: page size issues on a Loongson system), I gather uClibc does (or, at least, did) work fine on Cobalt mipsel machines. Does anyone have any ideas or suggestions? I don't think I'm motivated enough to start from scratch with uClibc's buildroot. |
|
| Back to top |
|
 |
mattst88
Developer
Joined: 28 Oct 2004
Posts: 422
|
| Posted: Tue Jul 19, 2011 6:14 pm Post subject: |
|
|
Is there some compelling reason to use uclibc (and its associated headaches) over glibc?
I hear people say glibc is 'bloated' but I don't ever hear any comparisons or actual numbers.
In short, you're on your own for uclibc/mips stuff for the time being. We don't currently have uclibc/mips profiles.
_________________
My Wiki page |
|
| Back to top |
|
|
Sanguinary
n00b
Joined: 17 Oct 2004
Posts: 16
|
| Posted: Wed Jul 20, 2011 1:36 am Post subject: |
|
|
| mattst88 wrote: | Is there some compelling reason to use uclibc (and its associated headaches) over glibc?
I hear people say glibc is 'bloated' but I don't ever hear any comparisons or actual numbers. |
In the strictest sense, there's no "compelling reason" to use an old, 250 MHz machine like the Qube 2 at all, but that's what I feel like doing. My intention is to build it essentially as an embedded device, using Compact Flash as the drive; in that role, uClibc makes sense. I've been through working with the Qube running Gentoo years ago, with such fun as crossdev on my amd64 machines being unable to build the same glibc as the Qube was using natively. I haven't checked to see if those problems persist (or, for that matter, if uClibc would work better)--I just feel like doing things differently this time around. Or, at least, exploring the possibility.
| mattst88 wrote: | | In short, you're on your own for uclibc/mips stuff for the time being. We don't currently have uclibc/mips profiles. |
But is "the time being" the same as forever? And is "we don't currently" the same as "we never will?" I understand this would never be a high priority, but given that Mips processors are typically found in small or embedded systems these days, a uclibc/mips (or, here, uclibc/mipsel) profile seems like an obvious fit. |
|
| Back to top |
|
|
roarinelk
Guru
Joined: 04 Mar 2004
Posts: 520
|
| Posted: Wed Jul 20, 2011 11:32 am Post subject: |
|
|
| Sanguinary wrote: |
But is "the time being" the same as forever? And is "we don't currently" the same as "we never will?" I understand this would never be a high priority, but given that Mips processors are typically found in small or embedded systems these days, a uclibc/mips (or, here, uclibc/mipsel) profile seems like an obvious fit. |
glibc isn't that big (2.13-r4 is ~2MB built with -O2), and you get to benefit from
your CPU's MMU. The overwhelming majority of embedded MIPS in
the field has an MMU (including everyhting OpenWRT runs on); only the PIC32 is
a MMU-less R4K derivative which can't run glibc. |
|
| Back to top |
|
|
mattst88
Developer
Joined: 28 Oct 2004
Posts: 422
|
| Posted: Thu Jul 21, 2011 4:23 am Post subject: |
|
|
| Sanguinary wrote: | | mattst88 wrote: | Is there some compelling reason to use uclibc (and its associated headaches) over glibc?
I hear people say glibc is 'bloated' but I don't ever hear any comparisons or actual numbers. |
In the strictest sense, there's no "compelling reason" to use an old, 250 MHz machine like the Qube 2 at all, but that's what I feel like doing. |
Oh, don't bother with this kind of explanation. I'm a Gentoo/Alpha and MIPS developer. 
| Sanguinary wrote: | | My intention is to build it essentially as an embedded device, using Compact Flash as the drive; in that role, uClibc makes sense. I've been through working with the Qube running Gentoo years ago, with such fun as crossdev on my amd64 machines being unable to build the same glibc as the Qube was using natively. I haven't checked to see if those problems persist (or, for that matter, if uClibc would work better)--I just feel like doing things differently this time around. Or, at least, exploring the possibility. |
crossdev is always changing. Try it again.
| Sanguinary wrote: | | mattst88 wrote: | | In short, you're on your own for uclibc/mips stuff for the time being. We don't currently have uclibc/mips profiles. |
But is "the time being" the same as forever? And is "we don't currently" the same as "we never will?" I understand this would never be a high priority, but given that Mips processors are typically found in small or embedded systems these days, a uclibc/mips (or, here, uclibc/mipsel) profile seems like an obvious fit. |
I don't have any plans to do it. It'd be nice to have... I guess. I'm the only active MIPS developer, so I don't really see this changing soon, especially since I think glibc is a better option anyway.
It's a ton of work to support a second C library, and with me doing all the work, that's a tough sell, especially when there doesn't seem to be any actual reason to use uclibc.
_________________
My Wiki page |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
