Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49897 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22676 invoked from network); 11 Oct 2010 18:35:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Oct 2010 18:35:43 -0000 Authentication-Results: pb1.pair.com header.from=mamfelt@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=mamfelt@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: mamfelt@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-ew0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:42709] helo=mail-ew0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 43/64-27779-DF853BC4 for ; Mon, 11 Oct 2010 14:35:42 -0400 Received: by ewy24 with SMTP id 24so519531ewy.29 for ; Mon, 11 Oct 2010 11:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XdPVeb7EGow16iU/9FVr8JI4NoH8f3MOHQi3RQEo1lo=; b=WO6igSYGpjI20xZcVwuMmgv36ETkr/cdBEAcYp8xe7r6gHcN4QqRbdfqG64Jd9Rp6P 2P+NCt58NRF1yfjWxGCHJe18Ty3YlR6fn5bQb5Wz/Ueyrz4jG7c84nEZ7WTJanA8rLHV f+ZMhMw1/bGdA3RG4CYRETwi4jUdLZHAS4Hpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wgcmv6DViMzBJd8pVM5uB21N6fwTCH5ZGnVihEWbkG8/QWrYxuQ9FTZhayBOk/iqI4 kg7o8ZSqhiInRGM46s65di+VAXPigSDOsreAGHI1up94ZBow3Ab1c1YzM3+NW6GqkBeq hP2YFVIMbTOqRQ+tLyXbs3Q4xsyJHz/g0KKkw= MIME-Version: 1.0 Received: by 10.14.47.79 with SMTP id s55mr1967971eeb.46.1286822138443; Mon, 11 Oct 2010 11:35:38 -0700 (PDT) Received: by 10.14.127.78 with HTTP; Mon, 11 Oct 2010 11:35:38 -0700 (PDT) In-Reply-To: <4CB2E0C6.8070000@daylessday.org> References: <4CB0CCD1.6090408@acm.org> <4CB2E0C6.8070000@daylessday.org> Date: Mon, 11 Oct 2010 20:35:38 +0200 Message-ID: To: Antony Dovgal Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=90e6ba615522737a4204925ba01a Subject: Re: [PHP-DEV] Problems with iconv on AIX 5.3 and 6.1 - maybe a bug From: mamfelt@gmail.com (Michael Felt) --90e6ba615522737a4204925ba01a Content-Type: text/plain; charset=ISO-8859-1 Thanks Antony, I sort of found that out. I downloaded the gnu iconv and gettext, and ran them as libiconv, configure, install; tettext, configure, install; libiconv, distclean, configure, install; php5.2.13 config, make, test (better results), install - and the joomla migrate worked. Now - as one of my goals is to make installable packages - I need to figure out why "make dist" for libiconv (and maybe for gettext as well) does not work. As to 5.3 - personally, I have some oldish PHP code that does not like some of the new defaults in 5.3 (as least when I tried when it first came out). However, I shall soon do 5.2.14. There is another AIX idiosycrancy I found. It does not like the BUILD_CLI string in the Makefile. If I edit it into seperate lines and put those where $(BUILD_CLI) stands, the sapi/cli/php program configures fine. The other issue I run into is the, also oldish, libmysqlclient library I link against also has all the libz routines. I am assuming the code is using the libz routines - because libz is first in the shared libraries list. Fun in porting :) Off topic I know - but how much interest is there is a more explicit "debug" info of the BUILD_CLI issue. Personally I find it very strange as it used to work fine (the string does not look to have changed in a long time. I would guess it is some security 'improvement' in make or ksh. On Mon, Oct 11, 2010 at 12:02 PM, Antony Dovgal wrote: > On 10/10/2010 12:13 AM, Michael Felt wrote: > > I think it is a bug, but it might also be a misunderstanding. > > > > Background: I am trying to convert Joomla 1.0.X to 1.5.X and ran into > > problems with the conversion of the database that is done during the > > migration. I started out by doing several of the tests/samples in the > > php manuals, but always got blank results. I tried changing the php.ini > > settings: > > [iconv] > > iconv.input_encoding = ISO8859-1 > > iconv.internal_encoding = ISO8859-1 > > iconv.output_encoding = ISO8859-1 > > Well, yes, it's a known problem that AIX contains it's very own version of > iconv. > At least it differs from everything else I've seen so far (in terms of > encoding names and functionality). > > > #else > > REGISTER_STRING_CONSTANT("ICONV_IMPL", "unknown", CONST_CS | > > CONST_PERSISTENT); > > #endif > > REGISTER_STRING_CONSTANT("ICONV_VERSION", version, CONST_CS | > > CONST_PERSISTENT); > > > > It seems my system is being configured, but under #else - "unknown". > > Probably "ibm" might be better, but it doesn't change much.. > > > I did some digging in configure. Once configures finds iconv (PHP > > version 5.2.13 line numbers!) > > You should look into ext/iconv/config.m4 instead. > ./configure is generated and it's not supposed to be read. > > Also I'd suggest you to try 5.3 branch, I can see that AIX iconv support > exists only there. > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --90e6ba615522737a4204925ba01a--