mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: dn_expand() confuses postfix
Date: Tue, 13 Aug 2013 16:36:35 -0400	[thread overview]
Message-ID: <20130813203635.GG221@brightrain.aerifal.cx> (raw)
In-Reply-To: <20130814030916.5d3cd1f2@sibserver.ru>

On Wed, Aug 14, 2013 at 03:09:16AM +0800, orc wrote:
> > > (btw running whole LAMP/FTP stack with musl - some issues appear
> > > like iconv need to be replaced with libiconv to make some CMS
> > > happy, so I have some compatibility experience here.
> > 
> > Do you know what problems they hit with iconv? It's my intention that
> > iconv not need to be replaced. My guess is that the issue is failure
> > to automatically detect UTF-16 endianness via BOM, or missing charset
> > aliases for some charset strings.
> 
> I don't know why some hacked-up CMS did not liked current iconv. But in
> phpinfo, iconv version shown as "unknown" which is probably traced to
> absense of /include/gnu/libc-version.h and I suspect that they check it
> or use some nonstandard extensions or PHP is mad. Building PHP 5.4
> statically with gnu libiconv.a reset version to known one and
> everything works.
> I need to ask our php hackers about this (they maintain stuff) or
> grep for all iconv which appears in sources.

Hmm, so it sounds like there's a good chance this is just a case of
hard-coding known iconv implementations, and either PHP itself is
refusing to use an "unknown" implementation, or it's reporting the
implementation as "unknown" to PHP web apps, which in turn are
refusing to use it because it's unknown. Does my assessment here seem
correct? If so, I don't think it's an issue musl can address, but
rather something we should work with upstream PHP or CMS maintainers
to get fixed.

> > > Musl much more perfect than I
> > > expected)
> > 
> > Great to hear. :-)
> 
> I replaced gnu libc stack with musl one on our middly loaded sites in
> large LAN/MAN and it works great and easier to maintain, fix and modify
> in a way you want :)

Nice. If you find anywhere musl seems to be giving you problems or
performance bottlenecks, let us know. This is definitely a family of
usage cases I'd like to make friendly. VE images especially are a
place where I feel like musl is appealing since it's so fast and
simple to build the system from scratch.

Rich


  reply	other threads:[~2013-08-13 20:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 18:19 orc
2013-08-13 18:38 ` Rich Felker
2013-08-13 19:09   ` orc
2013-08-13 20:36     ` Rich Felker [this message]
2013-08-14 22:06 ` Rich Felker
2013-08-15  6:14   ` orc
2013-08-15  6:36     ` Rich Felker
2013-08-25  6:43     ` Rich Felker
2013-08-25  8:42       ` orc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130813203635.GG221@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).