From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3886 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dn_expand() confuses postfix Date: Tue, 13 Aug 2013 16:36:35 -0400 Message-ID: <20130813203635.GG221@brightrain.aerifal.cx> References: <20130814021920.7e719d8f@sibserver.ru> <20130813183816.GF221@brightrain.aerifal.cx> <20130814030916.5d3cd1f2@sibserver.ru> 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 1376426206 24360 80.91.229.3 (13 Aug 2013 20:36:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Aug 2013 20:36:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3890-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 13 22:36:49 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 1V9LKj-0002EN-Co for gllmg-musl@plane.gmane.org; Tue, 13 Aug 2013 22:36:49 +0200 Original-Received: (qmail 17459 invoked by uid 550); 13 Aug 2013 20:36:48 -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 17448 invoked from network); 13 Aug 2013 20:36:48 -0000 Content-Disposition: inline In-Reply-To: <20130814030916.5d3cd1f2@sibserver.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3886 Archived-At: 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