Explanation on differences between glibc toolchain and newlib toolchain

[Dilan Manatunga]

Hi,

I've been looking around but I have been unable to find a good, clear explanation on the differences between using the glibc toolchain versus the newlib toolchain. Could you someone please help me understand their difference?

-Dilan

[Brad Chen]

Hope this helps:

The glibc toolchain uses the GNU implementation of the libc runtime. The newlib toolchain uses the newlib implementation of the libc runtime.

Here are some common reasons you might want to use the GNU libc implementation:

• Linux source will build more easily
• It has better performance in many useful cases
• It supports dynamic linking
• It uses the GPL open source license

Here are some common reasons you might want to use the newlib libc implementation.

• it does not use the GPL open source license

To many it is a surprise that you can't change libc implementations without rebuilding the compiler and adjacent tools. And yet, it is so.

Brad

-Dilan

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/myfFDgu4ux4J.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Roland McGrath]

In fact, glibc uses the LGPL license and newlib uses neither GPL nor LGPL.
GPL vs LGPL is a very important distinction for application developers and
it's of crucial benefit to application developers (those who don't want to
release their own code under GPL anyway) that glibc's license is LGPL.
Just using dynamic linking is the trivial way to comply with the LGPL
requirements, though it's entirely possible to use static linking and still
comply with LGPL (but takes more work on the part of application developers
and redistributors--and it so happens, for wholly unrelated technical
reasons, that our SDK team does not support static linking using the glibc
toolchain). But those who don't want to think about licensing issues at
all often prefer to avoid LGPL as well as GPL, and for them newlib has the
benefit of a much simpler and more permissive license.

[Dilan Manatunga]

Sorry if there are some basic misunderstandings in these questions, but for glibc or newlib are the libraries that are linked against also nacl-compatible. Aka, would the validator view them as valid?

-Dilan

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.