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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
