On Thu, Apr 25, 2013 at 12:15 AM, Rich Felker <dalias@aerifal.cx> wrote:
The recent thread "Best place to discuss other lightweight libraries"
had me thinking we should really put together a list of high-priority
library replacements that need to be done.

Sounds like a great idea.
 
1. A light, C, UTF-8-only Unicode library. The most important things
it should implement are things needed by any application that presents
text to the user, specifically line-breaking (UAX#14), bidi (UAX#9),
identifying grapheme clusters, etc. Things like case- and
normalization-insensitive comparison, application of Unicode-format
collation rules, etc. would also possibly be useful.

I have something I'm working on that I'm using for my sdcv port.  It mainly covers things like switching from utf8 to uint32_t and back and utf8 equivalents of isspace, isdigit, toupper, tolower, etc.  I really like the Plan 9 rune implementation.  I didn't need all the functionality of the Plan 9 library, so I'm creating a small library with just the minimal functions I need.  If you check Ohloh, I've also seen some examples of internationalized versions of standard functions like isdigit, isspace there.
 

2. SSL.
...
Unfortunately, all of the existing SSL
implementations are bloated, buggy, and fail even the most basic
robustness requirements. A good solution would be based on tomcrypt
and would expose a minimal, simple API suited for event-loop-based or
threaded use. It may also be useful to have an optional wrapper layer
to expose an API that mimics openssl or gnutls.

I think an openssl wrapper and possibly a gnutls one would be essential if you want to have it work with all the Open Source programs already out there.

There are three main options I currently know about: openssl, gnutls, and nss.  Each has a different license.  So depending on how a program is licensed, you may not legally be able to use some of these libraries with the program.  Any GNU licensed program requires an optional waiver to link with openssl.  You find many Open Source programs provide the optional waiver.  One really good example of the license issue concerns lynx.  You can check their mailing list for a detailed discussion.  The highlights are that lynx is GPLv2 and the project can't contact all the authors who worked on it to change the license or get a waiver for linking to other types of incompatible licenses.  The openssl library can't be used with a GNU program unless there's a waiver for it because one of the clauses in the openssl license goes against the GNU license principles.  The gnutls openssl compatibility wrapper is GPL v3, so it can't be used unless the program is relicensed at GPL v3 ( http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ).  That just leaves nss licensed under MPL, LGPL and/or GPL.  If it's LGPL, lynx can use it.

Moral of the story, if anything's going to be done to replace these libraries, it would have to be under appropriate license(s) or one would not be able to use the results with existing Open Source software already out there without violating copyright.

 3. Image format and compression (libpng, zlib, etc.).

A good SVG library is needed.  To get SVG into Tuxpaint, it added libcroco, librsvg2, libcairo and other GTK+ library dependencies.  Tuxpaint is based on SDL, so would prefer not to see all the added code for two GUI libraries.  Someone was recently asking on the SDL list about SVG library options that are actively supported.  The only one with active  support that I could locate (besides librsvg2) was the one used by netsurf ( http://www.netsurf-browser.org/projects/libsvgtiny/ ).

If you're looking at graphics formats.  You might as well add audio formats to the list too.  There are a wide variety of libraries for the different audio formats and they range in quality (and license types).
 
That's all I can think of at the moment but I'm sure there are other
needs I've come across and forgotten. Please feel free to supplement
this list.


As already mentioned, libintl is on my list of things to replace if possible.  pkg-config has a nice replacement in pkgconf.  (If a list is created, might be helpful to list possible replacements already out there.)  Would like to see some of the pieces that are essential parts of the GNU build system/autotools replaced with some more efficient alternatives.  It's easier to keep using the GNU autotools system than to completely replace it with a new design.  Replacing it with another system completely would mean switching over any program or library one wants to build from the many Open Source programs already out there that currently use it.  The CoApp project is attempting to do that on Windows (switch other build systems over to the one used by Visual C++).  Seems like a lot of unnecessary work to port applications.  Would rather see the current build systems already used (autotools, cmake, etc.) streamlined or see drop in replacements that are better designed.

One other area that can be troublesome is when there are multiple libraries with similar functionality and some of the programs you want to build use one while the rest use another.  The openssl/gnutls/nss example is an issue.  It's typically solved by supplying wrapper interfaces.  The case I keep running into at the moment is libxml2/expat.  libxml2 is newer and works in conjunction with libraries like libxslt.  Some Open Source programs let you pick one or the other.  Unfortunately, there are some that insist on only one.  Makes it hard to simplify one's system down to just using one XML library. 

Sincerely,
Laura