We have been tossing this back and forth on #cemetech for weeks now; we need to get PrizmSDK 0.4 out of the pipeline already. Specifically, a few of us have had libm, libc, and the greatly-expanded libfxcg for quite some time, but everyone grabbing PrizmSDK 0.3 is left out in the cold. Based on discussion on IRC, it sounds like the main sticking point is just getting everyone coordinated on packing the new includes and libraries together, with a secondary concern about whether to continue including the Windows executables for the compiler, assembler, linker, and other cross-compilation toolchain tools. I am strongly in favor of keeping them, so that our Windows users (which, let's face it, is the majority) will still be able to simply unpack and use PrizmSDK 0.4. I feel that if we leave them out, people will be left with having to follow scads of inscrutable instructions, which was one of the problems with Simon's miniSDK in the first place.
Thoughts?
I use Windows. XP and 7 starter, so it would be nice if you could include Windows Executables.
The one thing I'd like to get working for a new release would be gcc and binutils targets for prizm, greatly simplifying the build process.
I have
binutils compiling okay (but haven't gotten around to creating linker script templates for prizm yet), but
my gcc patch currently fails to build with the sh4a-elf-prizm target, and I haven't found time to debug the build. I'd welcome input from others, though.
I was half waiting for Tari to finish his work on that and half for work to hopefully slow down enough for me to not be working constant 50hr work weeks but it doesn't look like that second part is gonna happen any time soon.
If someone is willing to put something together that they think is releasable run it by Me, Merth and Tari. If none of us have any complaints then I'll call it a release. Heck if you can please Merth I'll call it good enough. He uses the SDK the most out of the people working on it and he has a good eye for polish.
That sounds fine to me, Jonimus. Tari, in what way would that be different than what we have now? Would the main point of that be to remove the need for mkg3a?
KermMartian wrote:
That sounds fine to me, Jonimus. Tari, in what way would that be different than what we have now? Would the main point of that be to remove the need for mkg3a?
It would allow us to simplify the build flags and remove the need for external linker scripts and start routines. Aka Prizm.ld and the crt0.s, the crt0.s has been built into libfxcg for a while but moving it to the toolchain would be a bonus. It would also allow us to tweak the default CFLAGS the compiler would use to be more prizm specific rather than having to manually do so in the Makefile.
Note: GCC needs to be compiled with these extra arguments:
Code: --enable-sjlj-exceptions --disable-hosted-libstdcxx
(Edit: also, the configure script needs to be patched as it tries to do something odd and the binutils for the prizm doesn't support it)
This is required for C++ support. The first one changes the exception handler to sjlj. This is because I couldn't get the current exception handler to work on the prizm (blaming the linker script). The second one lets you compile libsupc++, required for getting C++-specific code to compile.
You need to patch gcc/libstdc++-v3/libsupc++/eh_exception.cc to remove exception handling:Code: #include "typeinfo"
#include "exception"
#include <cxxabi.h>
/*
std::exception::~exception() throw() { }
std::bad_exception::~bad_exception() throw() { }
*/
abi::__forced_unwind::~__forced_unwind() throw() { }
abi::__foreign_exception::~__foreign_exception() throw() { }
/*
const char*
std::exception::what() const throw()
{
// NB: Another elegant option would be returning typeid(*this).name()
// and not overriding what() in bad_exception, bad_alloc, etc. In
// that case, however, mangled names would be returned, PR 14493.
return "std::exception";
}
const char*
std::bad_exception::what() const throw()
{
return "std::bad_exception";
}
*/
crt0.s needs to be patched as it has an issue where it never calls global class initializers.
You also need to add in a new build target:Code: make all-target-libstdc++-v3
make install-target-libstdc++-v3
Once this is done, the libgcc and libsupc++ will be corrected. uClibc++ can be built.
Now, the headers need to be mucked with. You will need to add all of the headers from uClibc++ and quite a few from uClibc. libm needs to have the patched uClibc headers and libm sources to compile.
-----
When you need the patches, changed files, or anything, let me know. My changes are not on github. KermM has a copy of my include/ and lib/ folder (hopefully with all libs)
For the sake of getting the current libraries out to the masses quickly, how do you guys feel about packaging the current executables with the new libraries and includes, releasing that as 0.4, and then worrying about an improved build system for another incremental release? That could be 0.4.1 or 0.5 or something. Just my tuppence.
KermMartian wrote:
For the sake of getting the current libraries out to the masses quickly, how do you guys feel about packaging the current executables with the new libraries and includes, releasing that as 0.4, and then worrying about an improved build system for another incremental release? That could be 0.4.1 or 0.5 or something. Just my tuppence.
This is what I was going to say--it seems to me that getting something better out there is better than waiting for something even better when we can just make incremental releases.
Reasonable enough. From my usual perspective of ignoring C++ support (
), throwing one of my automatic libfxcg builds into a package with toolchain binaries will do the job.
I know ahelper had done work on file I/O particularly, but I'm somewhat concerned about licensing on that stuff, since much of it is copied wholesale from uClibc, which is licensed under the LGPL. This brings up the issue that we still haven't codified a license for libfxcg.
Personally, I don't like using GPL variants, and would much prefer to put libfxcg under a BSD or zlib license, but that's incompatible with the LGPL that applies to the uClibc parts (see
ahelper's fork repository). My first thought is to do away with the uClibc code (at least in the core) and rewrite it to fall under a more permissive license.
For things like libm, I'd be willing to put that under LGPL, since the cleanliness of that code is mostly independent of the system it runs on top of, and there's no existing implementation in libfxcg for it to clutter up.
Hmm, file I/O is one of the big things that I'm happy to have now; my understanding was that we wrote that stuff from scratch. The things I thought that AHelper pulled in from uClibc were stdio/stderr/stdin things, which I'm happy enough leaving out in favor of using PrizmIO anyway. Where does that leave us for the 0.4 release? Can we not release AHelper's current builds without irreparably breaking licensing terms?
I don't know, because it looks like most of it isn't in git. I'd have to be able to see the code (cough) to say.
Tari wrote:
I don't know, because it looks like most of it isn't in git. I'd have to be able to see the code (cough) to say.
I believe he said he checked it all into his branch of libfxcg?
https://github.com/AHelper/libfxcg/tree/new-syscalls
Didn't even think to look at branches.
Anyway, there's not a lot in there and it looks okay from a licensing perspective, but the quality of the code itself leaves something to be desired. I just left a number of comments on the
largest commit.
Neat. I see that the two of you are going back and forth in the line notes, which makes me happy. I look forward to progress, and tell me if there's anything I can do to help advance things faster.
I will, when I have a large amount of time, get libm added to github, patches and all, as well as uClibc++. Note that in order to actually use
the new crt0.s and a patched libgcc.
Now, I am able to cleanly build everything with my libfxcg, so getting it on github shouldn't be an issue so long that libgcc and libsupc++ are compiled properly. (uClibc++ requires the actual libsupc++.a file for compilation)
I will improve it, but again, I don't have time.
I would think that libm is a priority here over uClibc++, since most of us write Prizm programs in C rather than C++. How extensive were your changes to libm to get it to work for the Prizm? Is it feasible to get it ready in a few days or a week, so that it can be included in PrizmSDK 0.4?
A cursory look at some of uClibc's libm source seems to indicate it's pretty easy to build. No guarantees, but I can poke at it if Ahelper isn't interested/able.
libm is easy to get if you have all of the configuration headers and uClibc headers included. There are some changes and I will commit them when I get time. Although, uClibc++ is much easier to get working that uClibc was.
So where do we stand on this? People continue to pester me daily on SAX for PrizmSDK 0.4.
