Perl - undefined symbol error since -current updates
 

G'Day,

After the updates on Friday 13th (32bit) I seem to have a broken Perl installation. The error message I get when any perl program that uses a database is:
Unfortunately, I don't know where to start looking for a solution. Any pointers would be most helpful.

Thanks, BG4.

try a clean install instead of an update

Something is broken DBI.so is part of the perl package, your path indicates perl-5.12.3 but -current is perl-5.16.0.
How did you update perl?

Thanks for the replies.

I did a "slackpkg update" "slackpkg install-new" "slackpkg upgrade-all". The mirror I used was the tds.net one.

I have tried a "slackpkg reinstall perl" which comes up with "perl-5.16.0-i482-2.txz" as the package installed. But it made no difference.

Out of desperation I have renamed the 5.12.3 directories to 5.16.0 and it seems to have solved the problem....I will test further.

Thanks for the suggestions..

BG4.

It looks like you've upgraded DBI and then upgraded the Perl package installed on your system (your offending DBI is in site_perl and Slackware's is in vendor_perl, with modules in site_perl taking precedence).

Ideally, you want to remove modules compiled/installed under 5.12.3 and reinstall them under 5.16.0. It doesn't matter for pure-Perl modules (assuming they'll still work with new versions of Perl's core modules, which they will, because that's how Perl rolls), but with XS modules like DBI you'll run into problems.

will fix you.

Solved
 

Thank you CTM,

That fixed the problem. All good now, thank you.

BG4

bumping an old post with a related question.

If I reinstall a module under the later version, will the module still work when run with an earlier version.

Context:
we have scripts shared across multiple servers which are access via a mounted volume. Each server uses a local version of perl, and the perl versions are not consistent. The module in question (Kx) was installed with an older version and is bombing when run with a local instance of perl 5.16.3.

In a perfect world, I can rebuild with 5.16.3 and still have the script work with 5.10 or other older versions. If not I'll have to probably include a perl build on the shared mount and refactor a lot of scripts. Is the former possible?

It should be possible, provided:

• your scripts on the shared volume don't have a hard-coded dependency on a particular version of Perl (e.g. "use v5.16")
• you install your modules on each local perl your intend your scripts to run on
• the modules themselves don't have a hard dependency on a particular version of Perl

interestingly, just for kicks I built another perl instance of the correct version (5.10.1) and the module in question would not work with it. It seems it will only work with the specific instance of Perl it was built with. Which is unfortunate.

Its quite possible that other factors such as glibc might be at play (at least for -current, since glibc-2.26 has some breaking changes.)

I think more probably are the binary incompatibities (modules included) between some of the recent perl 5.x versions and that lead to segfaults...

I suppose that depends on dsbx if s/he can provide logs of the module build failures

but as I understood what he wrote I don't think he got issues *building* modules: he wants to use modules built on one perl version on another perl version that most probably is binary incompatible with the first and that leads to a segfault when *using* the modules on a different perl version from the one they were built over.
to avoid that he really should rebuild the modules that he wants to use with the second perl version on that one.

it's also possible that I haven't understood what he wants to do ;)

You are correct. The original perl version is 5.10.1 and this is what the module was built with. The 2nd is 5.16.3, and this is the version for which i first saw the error.

I built a third version in my home dir, also 5.10.1, and got that same error when using the module.

This behavior is strange bc:
- the module is installed to a path on my mounted home dir so it is available across many servers
- the perl build used on each system is a local build that lives at /usr/bin/perl, and has historically been v5.10.1
- i have not seen this issue for any other server

When i get to work i can provide more info on OS versions

can you provide more info on the "error"?