Skip to content

Conversation

@ComputerNerd
Copy link
Contributor

This pull request was motivated primarily by the desire to compile mupdf for the casio prizm. I was successful but it runs out of heap.
This time I did make sure that any third party code came from BSD or compatible licensed code/headers.
So here is what this pull request improves upon

  • Headers primarily from freebsd allow for many programs to compile that are just including it for a #define or whatnot. Even if the function is not implemented that is ok, the user will just a linker error which still puts us ahead of where we were before which the program will not even compile due to a lack of said header.
  • A math library. This is based on fdlibm and pulled from newlib. Yes newlib does contain some gpl code but not this, the code is under the same license as fdlibm which is even more permissive than the 3 clause BSD license as that is what such code is derived from. Some code in the libm folder is also licensed with the 3 clause BSD license. That shows that the licenses must be compatible if such is a concern.
  • Some minor improvements to some existed functions mainly a bugfix in sprintf where the string is not null terminated. Support (that is not enabled by default) for showing stderr using the same macro used in exit. Also if DEBUG is defined when compiling libc malloc will display an error message on screen and loop using GetKey and display how much memory is allocated using printf.
  • More standard C functions and some stubs for some posix functions.

@tari
Copy link
Collaborator

tari commented Nov 28, 2014

This is waaaay too much stuff for me to evaluate in only one commit.

As it stands, I really don't want to pull in huge piles of headers like this- it just makes everything hard to work with. I'd say compile-time errors because we don't define something are more sensible to deal wtih than link-time errors as well; defining something and not providing actual meaning to it is just misleading.

The rest of it is probably okay, but I simply can't evaluate a blob commit that touches more than 600 files where some of them are completely new and others have small changes. Break this up into multiple commits and probably even multiple PRs, then I'll look at it again.

@ComputerNerd
Copy link
Contributor Author

Alright I will do such. How small of changes do you want for example my idea was this. A pull request for the math library. A pull request for any posix related functions. Another for any additional headers. Also I personally do not find having the headers that define a few functions that may not yet exist misleading. Like I said before sometimes headers are used for only a small subset of what the header contains. It makes it easier if you want to compile a particular program, that way you can just look at a list of undefined functions and implement them or create a stub for them if the function is not critical to operation of said program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants