libc builtin vs system mixup

[obastemur]

Working on OSX, builtin libc is pretty mixin up with the one from system. I could contribute this part though but have some questions first;

• preferred libc target should be the one built-in right ? IMHO Yes.
• for the sake of testing / stability etc. why not separate jerry_libc project ?
• main_linux, main_darwin etc. could benefit lots of improvements and they could be combined into a single file. Agree / disagree ?

[egavrin]

Your contribution to libc would be really helpful to us, thank you!

• Yes, preferred libc should be the built-in one.
• We thought about separating jerry-libc, but for now it's not mature enough to be a separate project, or to be used with other projects like IoT.js. From the view of testing - currently, all default testing environments of the engine have jerry-libc, so any commit tested by developer or by our CI checks the libc.
• Absolutely, main_* should have commons parts that can be shared across the platforms.

[seanshpark]

I'm also interested in this subject, and agree with @egavrin

[LaszloLango]

• after Introduce 'USE_COMPILER_DEFAULT_LIBC' cmake option for switching from jerry-libc to a libc, provided by compiler #331 is merged, you are able to use the compiler's default libc
• Merge main-linux.cpp and main-darwin.cpp to main-unix.cpp for easy maintenance. #819 is also merged, so there are no separate main_linux and main_darwin files.

The tests are currently failing on OSX, so any help with fixing it is welcome. For details see our travis builds: https://travis-ci.org/Samsung/jerryscript