Newlib support?

[doragasu]

I suppose this has already been asked, but I could not see any other (opened or closed) issue about it, so...

Could it be possible to add newlib support? I have used it on microcontrollers with far less RAM than the MD and it's lightweight. In fact the Linux based toolchain has newlib support, and generated ROMs have a similar footprint as the ones generated with this toolchain.

I also miss a lot stdint.h...

[Stephane-D]

Well that requires recompiling the newlib for Mingw GCC 3.4.6 :p May be doable but i never did it myself and i don't know if that is easy (looking in google compiling newlib for 68k target is definitely not that easy). If i can find a pre compiled newlib i may try :)

[doragasu]

Thanks a lot for taking it into consideration. Building these things in Windows is usually a PITA.

[Stephane-D]

Haha yeah that is the problem. I'm using windows and I have to use Mingw builds which make things worst.

[doragasu]

Is this still under consideration? I need newlib for a few things, but it clashes with SGDK implementation of standard functions :(

[ijacquez]

Could you elaborate on what you need?

[doragasu]

I have developed MegaWiFi carts (WiFi enabled cartridges for the Megadrive). To build the Megadrive side API (https://github.com/doragasu/mw-api), I rely on newlib for some obscure functions such as setjmp/longjmp. I am also a heavy stdint.h user.

[ijacquez]

In the interest of unblocking you, would it be more beneficial to bring in setjmp and longjmp directly from Newlib?

stdint.h I believe comes with newer versions of GCC.

Newlib is great, as you mentioned 3 years ago, but personally, I find it to be too large for game development.

[doragasu]

Although I would rather prefer having complete newlib support, I think having setjmp/longjmp and stdint.h could be enough for me.

Newlib is big, but if properly built and linked (using -ffunction-sections and -gc-sections for linking), only the stuff you directly use is embedded in the ROM, so unused stuff does not bother.

[Stephane-D]

@doragasu I tried to compile newlib for newer GCC but to be honest i don't want to include it directly in SGDK, it will make SGDK library much heavier and almost nobody will use it as there is no real use of it for Megadrive development (except for very specific case as your). As ijacquez suggested, i think it would make more sense to import needed functions or link the library directly with your project than include newlib into SGDK.

[doragasu]

@Stephane-D I understand almost nobody needs newlib, and I am perfect with it not being included by default in SGDK. The problem I have is that SGDK is not compatible with any other standard library implementation. It would be great to have a way to build it against newlib or any other implementation of the standard library functions (maybe via #ifdef guards on standard library functions provided by default on SGDK, or a similar mechanism).

[ijacquez]

Having a define (USE_SGDK_STDLIB) that can be defined by default would be great. @doragasu can then undefine it and drop in Newlib directly.

Not having it defined and not having proper replacements for all functions should result in compilation errors.

[doragasu]

@ijacquez That would be great

[Stephane-D]

No problem in doing that, do you know which methods in particular need to be safeguarded against newlib ? thinking about base type definition ? memcpy / memset ?

[doragasu]

Thanks!

I think guards are needed for functions typically found in string.h: memcpy, memset, strcpy (and variants), strcmp (and variants), strcat, the abs mathematic function, and also for printf variants (typically in stdio.h).

Also types defined by stdint.h need guards, but it seems they are already in types.h.

Maybe that's all, but I might be missing something, as I have not checked the complete SGDK API.

[Stephane-D]

Thanks ! I will try to add that then :)

[Stephane-D]

Pushed changes for that, i will complete and fix it if with time.

[doragasu]

Thanks, I will test is as soon as I get the time!