Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14250 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56647 invoked by uid 1010); 31 Dec 2004 05:40:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 56594 invoked from network); 31 Dec 2004 05:40:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Dec 2004 05:40:32 -0000 X-Host-Fingerprint: 66.198.51.121 lerdorf.com Linux 2.4/2.6 Received: from ([66.198.51.121:47754] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity HEAD (r3992M)) with SMTP id 54/73-10264-B46E4D14 for ; Fri, 31 Dec 2004 00:40:28 -0500 Received: from lerdorf.com (lerdorf.com [66.198.51.121]) by colo.lerdorf.com (8.13.2/8.13.2/Debian-1) with ESMTP id iBV5e87v024207; Thu, 30 Dec 2004 21:40:08 -0800 Date: Thu, 30 Dec 2004 21:40:08 -0800 (PST) X-X-Sender: rasmus@colo To: Jani Taskinen cc: internals@lists.php.net In-Reply-To: Message-ID: References: <41D46CE5.2050101@lerdorf.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] generate ltmain.sh? From: rasmus@php.net (Rasmus Lerdorf) On Fri, 31 Dec 2004, Jani Taskinen wrote: > On Thu, 30 Dec 2004, Rasmus Lerdorf wrote: > > > We have ltmain.sh in our cvs. It is from an old libtool and not compatible > > with newer libtools. Specifically the shared_ext is not defined so we end up > > generating libraries without the .so extension. > > A simple rm ltmain.sh && libtoolize --force fixes it, but is there anything > > stopping us from either shipping a newer ltmain.sh (it seems to be backward > > compatible) or not shipping one at all and doing a libtoolize --force from > > buildconf? > > Actually we should always be using the generated libtool, whatever > libtool you might have installed. The reason to bundle libtool is to > have one variable out of the equation with different build environments, IMO. > > Exactly how do you get the problem with shared_ext..? I get libs/libphp4 without an extension created. Same for shared modules. This happens on both FreeBSD and Linux with libtool-1.5.2. Removing the bundled ltmain.sh and running libtoolize --force it fixes it. I tracked it down to that shared_ext not being defined in our ltmain.sh but correctly defined in the libtool-1.5.2 ltmain.sh which libtoolize creates. This is definitely the cause of this report: http://bugs.php.net/bug.php?id=26645 And I think it may also be the root of a lot of the people reporting libphp4.la gets created and no libphp4.so which a number of bug reports mention. -Rasmus