On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
But why would people do that on Solaris is my question.
For some reason it doesn't always identify that gcc is available (thats
how I noticed the problem). Don't ask me why someone would install the
XS version then switch to pure-perl. Never the
No, Dynloader's doing what it's supposed to, which is try to find an .so
for the module. The problem is that the one it finds is for the wrong
version.
No versioning information is written into the .so?
-J
--
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the blib directory.
bash-2.03# perl Makefile.PL --pm
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the blib
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the blib directory.
bash-2.03# perl Makefile.PL
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the
bash-2.03# perl Makefile.PL --pm
Why'd you do that? You told it to _not_ compile the XS version.
Because thats where the problem is occurring.
But why would people do that on Solaris is my question.
For some reason it doesn't always identify that gcc is available (thats how I
