From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3203 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Thu, 25 Apr 2013 08:51:21 -0400 Message-ID: <20130425125121.GN20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366894298 12433 80.91.229.3 (25 Apr 2013 12:51:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2013 12:51:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3207-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 14:51:38 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 1UVLeD-0000o8-V0 for gllmg-musl@plane.gmane.org; Thu, 25 Apr 2013 14:51:38 +0200 Original-Received: (qmail 24156 invoked by uid 550); 25 Apr 2013 12:51:34 -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 24144 invoked from network); 25 Apr 2013 12:51:33 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3203 Archived-At: On Thu, Apr 25, 2013 at 07:44:39AM -0400, LM wrote: > 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. This is somewhat different from what I was thinking of. You're looking more at replacing the standard C api functions for mb/wc stuff so you can work with UTF-8 regardless of the locale encoding. I was talking about importane Unicode functionality outside what the C API can provide. > 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. Agreed. The big question, I guess, is whether the aim would be to have big existing programs adopt it, or to provide just a new option for lighter programs. But since I think we'd want to be able to use many existing programs without dealing with the trouble of openssl and gnutls, I would lean towards the former as a goal. > 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 Not _used_ but _distributed_. The GPL does not restrict use whatsoever (and takes the position that it legally can't do so) so it's fine to use OpenSSL with GPL programs as long as you don't distribute the resulting binary. This is of course a problem for package maintainers/distributions, and distributing both openssl and the GNU program and a script to link them together might even be seen as an infringing activity. > 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. Agreed. I should have mentioned that all of these libraries should aim for permissive license (MIT/BSD) or at the very least, LGPL 2.1+, which while not as permissive, is at least compatible with all relevant foss licenses. > 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 Yes, I completely forgot about SVG, but really all modern UI and website graphics should be SVG, since raster images look hideous on modern 300+ dpi display devices (assuming they're interpreted as 96dpi, which they always are). > 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/ ). How complete is it? SVG rendering is rather difficult if you want to support all the features, and if you don't, lots of files will come out looking wrong... In particular if you want to support text, you need a font and layout engine, and you may need clones of "standard" fonts that people use assuming you'll have them because they're included with Windows... BTW, SVG is XML-based, but I don't think a good SVG library should need a heavy XML library. Rather, it should take shortcuts to interpret just SVG content in a less-bloated way. > 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). Yes and no. Audio and video are both generally a good bit more difficult than images, and fewer programs need these things. Images are needed by almost every interactive program these days both for interface elements and displaying content (which everyone assumes can display images), but audio is really only widely used for notifications, games, media players, and voice-chat apps. > As already mentioned, libintl is on my list of things to replace if > possible. Yes, gettext.. > 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 > [...] > 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. I seem to recall an effort somewhere to do exactly this, but I can't remember where I saw it.. > 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. In theory it shouldn't matter if more than one is linked, except for some additional bloat. In reality, there are sometime symbol clashes, especially when one is a forked version of the other... Rich