So, update on this: I've merged gbl08ma's changes, which clean up the headers somewhat as well as add some syscalls. Nothing new in libc with this.
For a release, we'll need to write up the changes necessary to users' makefiles to link against libc, since it won't link correctly with the old configuration.
I'd like to clean up the minicompat headers before a release, but that's pretty easy and could be done by just about anybody. Really, it's just documentation and packaging at this point.
May I ask where we stand on fopen, fgets, fclose, and friends? Do we have AHelper's versions, other versions, or no such thing? I know we can't pull in his libm stuff for being ripped from uClibc.
I had assumed it wasn't in his git branch, but I finally had a close look and
found it. There's a lot of churn where he changed spacing (note to potential contributors: avoid mixing spacing changes and actual changes in one commit), so it's a bit hard to read the diff. Looks reasonable, so I'll have a go at cherry-picking that change in the near future (probably tomorrow morning/afternoon).
I think you should include windows binaries but please make them separate from the library files it just slows down the download for GNU/linux users. Some (not saying all) Windoze users just can't follow tutorials like us GNU/Linux users.
Tari wrote:
I had assumed it wasn't in his git branch, but I finally had a close look and
found it. There's a lot of churn where he changed spacing (note to potential contributors: avoid mixing spacing changes and actual changes in one commit), so it's a bit hard to read the diff. Looks reasonable, so I'll have a go at cherry-picking that change in the near future (probably tomorrow morning/afternoon).
Took about 3 hours to get everything looking sane and compiling correctly, but I've just pushed the printing changes to stdio.
stdout prints to the screen, stderr prints to serial, and stdin reads from serial. I ruthlessly cut some things that weren't in use or redundant, such as "buffer streams" (I assume used for C++ support) and NULL checks on some input parameters (it's not the C library's job to check your parameters).
Been a while, y'all.
I've been working on an automated solution to build SDK packages, and it's mostly all working. For now, I'd appreciate some testing:
http://media.taricorp.net/prizmsdk
If you've been using git snapshots, there shouldn't be anything very new. Doesn't yet include sample Makefiles or anything.
Highlights since version 0.3:
- Lots of stdlib functions, particularly in string.h and stdio.h. Beware: stdio has not been well-tested.
- A small number of new syscalls, including Serial functions and PowerOff. Added headers describing keyboard support.
- Header reorganization. Casio-specific includes are now in the 'fxcg' subdirectory.
Please test, and let me know if there are any particularly handy additions you'd like in this release.
I invite you to check
https://github.com/gbl08ma/libfxcg and see if there's anything there that is interesting for adding to the official repo, namely the new syscalls.
I could just make a pull request, but judging by what happened last time I tried to contribute something, I got the impression it took Tari more work to cherry-pick my changes than if he were to add them manually.
AHelper wrote:
(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)
I am sorry for bumping this topic but I am attempting to compile libsupc++ for the casio prizm only to be encountered with errors that seem similar to what you are receiving what changes did you make to the configure file?
Edit: I ended up just using libsupc++.a from Ahelpers github repository it would still be good to know though for future reference what was changed.
KermMartian wrote:
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'd love Windows executables please as I cannot get libc to work in my setup and getting incredibly frustrated - please help. Many many thanks in advance
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
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
