At the moment, we are at least 4 know developers:
and me: Cyberic
I am not skilled enough to work on the kernel (except for some minor
But I had success porting apps to gp32linux.
Let's try to organise a bit:
As Ingeras said, we have to agree on a file standard hierarchy, and on
development tools. For instance, we should use the same cross compiler,
the same libc (uClibc or GNU Libc?), and so on.
Personally, I think that uClibc is great due to its light memory
footprint, but it sometimes makes some program unable/harder to compile...
Is there a way tu use both libs?
I should also mention the scratchbox project, which eases cross
compilation a lot.
Unfortunately I tried id with mplayer, and it crashed randomly... Maybe
this was because I used precompiled libraries bundled with scratchbox...
Fo the compilers, we have a working gcc-2.95 and gcc-3.3.1 (I think),
both based on uClibc.
The latter does not support large file functions, it is very annoying
for some software (like mplayer)
So I think we need a new one.
Tell me what you think.
From: Lucas Correia Villa Real <lucasvr@go...> - 2005-03-01 22:56:41
On Tuesday 01 March 2005 19:09, CybEriC wrote:
> Hi everybody.
> As Ingeras said, we have to agree on a file standard hierarchy, and on
> development tools. For instance, we should use the same cross compiler,
> the same libc (uClibc or GNU Libc?), and so on.
Well, I would tend to defeat gobolinux hierarchy, naturally :-)
I like it just to be able to keep each program on its directory, as I have
here for my gp32linux mini-distro:
BusyBox Fontconfig GoboHide JPEG LibPNG Matchbox SDL UClibc ZLib
Expat FreeType GPM LibOGG LibVorbis RXVT SDL_mixer Xserver
But I think we can discuss about this later; it's really just a matter of
having an easy way to ship packages and install them easilly.
> Personally, I think that uClibc is great due to its light memory
> footprint, but it sometimes makes some program unable/harder to compile...
> Is there a way tu use both libs?
Yes, but when using glibc you'll need to compile your project statically. I
don't consider using glibc on the distribution, as it's large both in memory
footprint and in size.
> Fo the compilers, we have a working gcc-2.95 and gcc-3.3.1 (I think),
> both based on uClibc.
> The latter does not support large file functions, it is very annoying
> for some software (like mplayer)
> So I think we need a new one.
I'm using a cross-compiler downloaded from codesourcery.com/gnu_toolchains.
It's based on GCC 3.4.2 and is generating very nice programs here. It's also
interesting to use a newer GCC release to be able to compile the kernel, as
GCC 2.9x will not do the job.
powered by /dev/dsp
Get latest updates about Open Source Projects, Conferences and News.