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?
-Rasmus
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..?
--Jani
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
Rasmus Lerdorf wrote:
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.
fwiw, I've had this various times since following 5.x as well as with 4.
>
>
>> 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..?
>
run buildconf from a cvs snapshot, and on some platforms (eg FreebSD 5)
it will make install will install 'libphp4' instead of 'libphp4.so'
-Paul