From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3200 Path: news.gmane.org!not-for-mail From: LM Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Thu, 25 Apr 2013 07:44:39 -0400 Message-ID: References: <20130425041553.GA13951@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6dbe089ae8ec04db2df1da X-Trace: ger.gmane.org 1366890293 31841 80.91.229.3 (25 Apr 2013 11:44:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2013 11:44:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3204-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 13:44:58 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UVKbd-0004dI-H9 for gllmg-musl@plane.gmane.org; Thu, 25 Apr 2013 13:44:53 +0200 Original-Received: (qmail 17739 invoked by uid 550); 25 Apr 2013 11:44:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17731 invoked from network); 25 Apr 2013 11:44:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2B2rTiKBGl0HHbUwWjmz5TbCFOlEWQt7fHeo1ZqIeWc=; b=z3sKnDt2z9Bv6K+w50hymUhxd3sztXfHFcYx0HCliOgrExlUzcok/HvZQ17Bvvz1y5 NnuIFBYL/4OBtgbJWNLBNMLXY57sj0iBhO5bS/tXk27DHTEtdmxfgCnKVGflhtYsSX4P Ij76ZFYdhy2byOQwWm2r8vaYom3MsMC5cUugCOHRZO/xIQlrIYniNoZB3Gnu1i3y0Gl0 ATGLCzIOER/lEWlGv7Ia22lxc4RgqaFo9Gmb2XtlYpgH99guV1xtTzWui6GMSfXs7JhB sZ/M4KbWYeC1T4y77ft1JFCxd+Op1OlTXdxzii41RXYmX8qUy8npEHi7pycnYUdxWwrp PWOA== X-Received: by 10.14.5.72 with SMTP id 48mr74347067eek.19.1366890280303; Thu, 25 Apr 2013 04:44:40 -0700 (PDT) In-Reply-To: <20130425041553.GA13951@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3200 Archived-At: --047d7b6dbe089ae8ec04db2df1da Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 12:15 AM, Rich Felker 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 --047d7b6dbe089ae8ec04db2df1da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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&q= uot;
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.
=A0
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.
<= br>I have something I'm working on that I'm using for my sdcv port.= =A0 It mainly covers things like switching from utf8 to uint32_t and back a= nd utf8 equivalents of isspace, isdigit, toupper, tolower, etc.=A0 I really= like the Plan 9 rune implementation.=A0 I didn't need all the function= ality of the Plan 9 library, so I'm creating a small library with just = the minimal functions I need.=A0 If you check Ohloh, I've also seen som= e examples of internationalized versions of standard functions like isdigit= , isspace there.
=A0

2. SSL.
...
Unfo= rtunately, 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 thin= k an openssl wrapper and possibly a gnutls one would be essential if you wa= nt to have it work with all the Open Source programs already out there.

There are three main options I currently know about: openssl, gnutls, a= nd nss.=A0 Each has a different license.=A0 So depending on how a program i= s licensed, you may not legally be able to use some of these libraries with= the program.=A0 Any GNU licensed program requires an optional waiver to li= nk with openssl.=A0 You find many Open Source programs provide the optional= waiver.=A0 One really good example of the license issue concerns lynx.=A0 = You can check their mailing list for a detailed discussion.=A0 The highligh= ts 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 othe= r types of incompatible licenses.=A0 The openssl library can't be used = with a GNU program unless there's a waiver for it because one of the cl= auses in the openssl license goes against the GNU license principles.=A0 Th= e gnutls openssl compatibility wrapper is GPL v3, so it can't be used u= nless the program is relicensed at GPL v3 ( http://www.gnu.org/licenses/gpl-faq.= html#AllCompatibility ).=A0 That just leaves nss licensed under MPL, LG= PL and/or GPL.=A0 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 n= ot be able to use the results with existing Open Source software already ou= t there without violating copyright.

=A03. Image format an= d compression (libpng, zlib, etc.).

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

If you're looking at graphics formats.=A0 You might as well add aud= io formats to the list too.=A0 There are a wide variety of libraries for th= e different audio formats and they range in quality (and license types).
=A0
That's all I can think o= f 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 thing= s to replace if possible.=A0 pkg-config has a nice replacement in pkgconf.= =A0 (If a list is created, might be helpful to list possible replacements a= lready out there.)=A0 Would like to see some of the pieces that are essenti= al parts of the GNU build system/autotools replaced with some more efficien= t alternatives.=A0 It's easier to keep using the GNU autotools system t= han to completely replace it with a new design.=A0 Replacing it with anothe= r system completely would mean switching over any program or library one wa= nts to build from the many Open Source programs already out there that curr= ently use it.=A0 The CoApp project is attempting to do that on Windows (swi= tch other build systems over to the one used by Visual C++).=A0 Seems like = a lot of unnecessary work to port applications.=A0 Would rather see the cur= rent 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 libra= ries with similar functionality and some of the programs you want to build = use one while the rest use another.=A0 The openssl/gnutls/nss example is an= issue.=A0 It's typically solved by supplying wrapper interfaces.=A0 Th= e case I keep running into at the moment is libxml2/expat.=A0 libxml2 is ne= wer and works in conjunction with libraries like libxslt.=A0 Some Open Sour= ce programs let you pick one or the other.=A0 Unfortunately, there are some= that insist on only one.=A0 Makes it hard to simplify one's system dow= n to just using one XML library.=A0

Sincerely,
Laura

--047d7b6dbe089ae8ec04db2df1da--