The Gp2x Toolchain Project Has Begun

[Blah]

GCC has been updated to version 4.1.2!

 

[Mudi]

Are you going to have a means of compiling a dynamic-linking toolchain? I'm quite interested in being able to legally link LGPL stuff personally

The GPH dynamic linking toolchain is OK, but not ideal (I can't get software floats working at all)

 

[Blah]

Dynamic linking works, however you have to have a copy of a ton of .so (shared object, like gLibC, libGCC, etc.) files somewhere where your program can access them. I'm thinking of a easy way to do this, I could go with an unofficial firmware update (somewhat dangerous), convince Gamepark to update their libs, or just distribute a package you can put on your SD or NAND.

Oh and it is legal to link LGPL libs statically, as long as you make the object files available so that someone in the future may relink them. This toolchain can do static linking of course.

But first I want to make building the toolchain more convenient and add some libs to the kit. And I want one last shot at getting gLibC 2.4 and binutils 2.17 going.

 

[Mudi]

I really want a glibc 2.2 based toolchain that actually works with softfloat and everything, and I'm too lazy for the moment to figure out crosstool. I never use the new glibc features anyway, and I think the benefits of dynamic linking outweigh the newer features anyway.

Just my opinion, of course.

 

[Blah]

Originally I was heading that direction, but then I realized that to be perfectly compatible you must also use an old version of libgcc, which means using gcc-2.95. So in other words I don't think that's really possible.

But one of my goals is to make dynamic linking easy, so we can keep up with Torvalds. Also the libraries package should be less than 10mb zipped, so size isn't a big issue.

edit: Hmm, the ARM architecture is no longer supported by gLibC (since version 2.4), damn coders.

 

[Orkie]

Dynamic linking works, however you have to have a copy of a ton of .so (shared object, like gLibC, libGCC, etc.) files somewhere where your program can access them. I'm thinking of a easy way to do this, I could go with an unofficial firmware update (somewhat dangerous), convince Gamepark to update their libs, or just distribute a package you can put on your SD or NAND.

The easiest way is to wait for an open2x firmware release - I've certainly been working on updating the libraries, don't know about anybody else

 

[DJWillis]

edit: Hmm, the ARM architecture is no longer supported by gLibC (since version 2.4), damn coders.

Ahem? In what way do you see ARM as not supported in gLibC 2.4 then . My ARM EABI boards would be very upset to hear that as they use gLibC 2.4 just fine day in day out .

gLibC 2.4 is a major change for gLibC and the revisions to linux/posix threads are big but to say ARM is not supported is frankly wrong .

That said for the above reasons with threads and a few other good reasons I would not personally suggest gLibC 2.4 is a good choice for the GP2X. There are also big issues building it with GCC 3.* and as the kernel is a 2.4 series you can only build that with GCC 3.* at best.

If you want gLibC 2.4 then you may as well say goodbye to future dynamic linking options with the Open2x kernel/filesystem image we are working on as that is gLibC 2.3.6 based (and that is frozen for now).

gLibC 2.4 for ARM was all about supporting the newer EABI for ARM anyway, something we can’t use on the GP2X anyway (well unless somebody ported kernel 2.6.19> over to the GP2X when we were not looking ). ARM EABI is fantastic but not currently relevant to the GP2X (unfortunately).

Latest does not always indicate best when dealing with cross-compiling especially as often (historically) the changes in a release lead to regressions in non desktop architectures (i.e. ARM).

 

[Blah]

For me at least it gives me the compile error "error: the arm is not supported". Also for my copy at least the arm folder is missing in the sysdeps folder. Whatever, I'll just stick with 2.3.6.

And well, I'm too impatient to wait for an Open2x release, I'm going to find some way to make this work on GPH firmware for now.

 

[torpor]

Okay .. this is stupid. We've already done all the toolchain work needed to be done in Open2X .. and yes, the goal *IS* for Open2X to produce a toolchain for anyone to use to build compatible apps with the GPH firmware, or the Open2X firmware - by definition, the Open2X firmware is supposed to be 100% compatible with GPH, and thus: this starts with the toolchain. Why else do you think we already did 3x the work on the toolchain that you've done?

And .. it just doesn't make sense? Some sort of "Toolchain Fame Grab", Blah? Why don't you just join the existing guys working on making Open2X a viable and vibrant development toolkit, instead?

 

[Blah]

Well theres some things I hate about the libraries we have now, Rlyeh's minilib is a good idea but not GPL compatible, SDL could use some improvement in my opinion. Since I wanted to provide a complete solution for both processors, I felt it best to start with the toolchain and add some libs and other tools later. I didn't realize at first that the Open2x toolchain had all of this but that doesn't mean I'm giving up. But you wont see anything for a while, I've got the flu or something.

 

[Orkie]

Well theres some things I hate about the libraries we have now, Rlyeh's minilib is a good idea but not GPL compatible, SDL could use some improvement in my opinion. Since I wanted to provide a complete solution for both processors, I felt it best to start with the toolchain and add some libs and other tools later. I didn't realize at first that the Open2x toolchain had all of this but that doesn't mean I'm giving up. But you wont see anything for a while, I've got the flu or something.

You know, that 'justification' isn't very good

If you want to improve SDL, why not submit patches to the open2x SVN rather than splitting the project? How is making your own toolchain going to magically cause minlib to be GPL-compatible? What tools can you add to yours that you couldn't to open2x?

Basically, when the open2x firmware is released, your toolchain will be totally obsolete (there isn't much point to it now) as the open2x toolchain will provide all the same things, plus allow you to dynamically link with the wide range of libraries we are planning on including on the NAND. Currently, your toolchain *is* the same as open2x's, but when things move on, I won't be updating buildroot (what we're going to be using to build libraries and firmware) to work with yours.

Open2x's toolchain already has an easy to use script which is known to compile on lots of different platforms (with binaries on the way), so what advantage does yours have? People are already set up with toolchains that have been doing just fine so far - and we already have one for when things get shaken up (hopefully soonish now, I've nearly finished the base system ).

If you have any patches, I'm sure DJWillis will accept them into the tree - in fact I bet he'd be grateful, he's doing a lot of different things at once right now. If you have started this because you think it'd be hard to get patches into open2x, you are wrong. If it's good and it works, why wouldn't it?

Of course, you are quite welcome to do your own thing, but it is a complete and utter waste of time...

 

[torpor]

honestly. this is utterly boring, Blah. why are you forking and neglecting to participate in open2x-devel and such?

we've been here, we've done this. the point is: all you are exploring thus far was already mapped, documented, exploited. all that remains is the pimp. and here you are, pimping a fork?

 

[Blah]

Okay then.

But you realize DjWillis didn't put the crosstool based toolchain in the SVN until after I started this... Now that I have extra-sensory perception this will never happen again.

 

[torpor]

duh, he was trying to *help* you. thats the point of open2x.

 

[Blah]

How is making your own toolchain going to magically cause minlib to be GPL-compatible

The idea is to make a new minimal hardware library from scratch.

 

[torpor]

Put the energy into OPEN2X. Its quite feasible to construct an entirely minimal lib using the work we've already done.

 

[DJWillis]

Okay then.

But you realize DjWillis didn't put the crosstool based toolchain in the SVN until after I started this... Now that I have extra-sensory perception this will never happen again.

Blah,

I have no desire to get into a heated debate over this.

Mind you that raises an interesting question about why I am writing this reply but oh well.

I just want to point out that the Open2x crosstool modded scripts date back to 2005 (and earlier then that really as I used the scripts to build the pre-release dev kits for people)? Back then it was gcc-4.0.2, glibc-2.3.5 and binutils-2.16 based but the patch set has stayed very similar ever since.

Open2x note from back then.

The scripts lived in CVS until the project recently migrated over to the SourceForge SVN server. Admittedly the crosstool toolchain scripts where some of the last things to go over to SVN but hey, it has never been a secret that Open2x had a toolchain or 2 .

You can look at the old CVS repro at open2x.cvs.sourceforge.net if you want more development history.

Anyway, on the Open2x front…

To quote the Open2x Wiki about page

"Open2x is an umbrella project to bring open source, community friendly, solutions to the GP2X Linux handheld system. The project consists of a number of complementing sub-projects that work together to deliver and support things such as the Open2x toolchains and firmware."

That really sums up Open2x.

If you (or anybody else) want to help then please do, it is really appreciated (you can check out active projects on the Wiki and/or mailing lists). It is only thanks to people getting stuck in that the project has been making solid progress on a number of fronts recently. If you don’t want to get involved well I don’t personally mind (why should I?).

Good luck with your efforts, especially building a new hardware lib set from scratch.

 

[xhyldazhk]

Does any of the open2x toolchains allow to compile dynamically executables that run against the default GLIBC libs that are in the GP2X firmware? I think they are 2.2.5 or such...

I would like: lateast stable GCC (4.1.2 at this moment) plus a GLIBC compatible with the firmware one.

 

[DJWillis]

Does any of the open2x toolchains allow to compile dynamically executables that run against the default GLIBC libs that are in the GP2X firmware? I think they are 2.2.5 or such...

I would like: lateast stable GCC (4.1.2 at this moment) plus a GLIBC compatible with the firmware one.

Your out of luck then unless you build your own tool chain from source then .

GCC 4 and GLIBC 2.2 make for a horrid tool chain that is somewhat evil at the best of times .

Open2x tool chains link dynamicly just fine with the GLIBC used in the Open2x firmware (no supprise) but the effort and hacks needed to support dynamic linking with the stock firmware and a recent GCC is just not worth it (well in my view, and I have tried it many times ).