gp32linux-devel

[gp32linux-devel] Just a thread to see who is involved in the project

[CybEriC <cyb...@gm...>]

Hi everybody.

At the moment, we are at least 4 know developers:
Lucas
Ingeras
Toholl
and me: Cyberic

I am not skilled enough to work on the kernel (except for some minor 
patches)

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.

Regards
Cyberic

[gp32linux-devel] Just a thread to see who is involved in the project

[Florin A. <fan...@ul...>]

scractchbox provides
gcc toolkits uclibc or glibc
for some applications i think we have to use glibc ... :(

Re: [gp32linux-devel] Just a thread to see who is involved in the project

[Lucas C. V. R. <lu...@go...>]

On Tuesday 01 March 2005 19:09, CybEriC wrote:
> Hi everybody.

Hy Cyb,

> 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:

/Depot/GP32Linux/Programs] ls
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.

-- 
Lucas
powered by /dev/dsp