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
