Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Functions declared, but symbols missing #19

Open
Midar opened this issue May 16, 2015 · 3 comments
Open

Functions declared, but symbols missing #19

Midar opened this issue May 16, 2015 · 3 comments

Comments

@Midar
Copy link

Midar commented May 16, 2015

A lot of functions are declared in the header, but are actually missing, causing linking to fail, while compilation succeeds. Examples are gettimeofday(), sleep(), usleep() and fcntl(), to name just a few I found.

Since these are part of POSIX and not C99, it's perfectly fine to not have these - but they really shouldn't be declared in the headers then.

@autc04
Copy link
Owner

autc04 commented May 16, 2015

Well, it doesn't pay to modify the newlib-provided header files to provide only the exact subset of system calls currently provided by libretro.

@autc04
Copy link
Owner

autc04 commented May 16, 2015

The implementation of unix system calls is quite minimal at the moment. It's enough to allocate memory, and to do console output. File IO is not yet supported.

Contributions welcome.

There are also some decisions to be made; how much should be supported, and how much should be left optional to keep binary sizes down? (After all, it's bad enough that using iostreams pulls in all of listdc++'s locale support and fills half a floppy disk with unneeded code.)

Another idea would be to port/integrate GUSI: http://sourceforge.net/projects/gusi/

@Midar
Copy link
Author

Midar commented May 16, 2015

I agree that there's no real need to expose them, as they're only POSIX. I can see the argument of not wanting to introduce any diffs in newlib to make updating from upstream easier, as apparently, there's nothing to define to tell newlib what's not available. However, might this be something worth raising upstream for newlib? I know newlib is used for a lot of embedded stuff, including stuff that most certainly doesn't even have a real time clock or a file system ;).

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

No branches or pull requests

2 participants