[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130425125121.GN20323@brightrain.aerifal.cx>
Date: Thu, 25 Apr 2013 08:51:21 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
