Re: generate ltmain.sh?

From: Date: Fri, 31 Dec 2004 05:40:08 +0000
Subject: Re: generate ltmain.sh?
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-14250@lists.php.net to get a copy of this message
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

« previous php.internals (#14250) next »