LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Perl - undefined symbol error since -current updates (https://www.linuxquestions.org/questions/slackware-14/perl-undefined-symbol-error-since-current-updates-4175417121/)

bg4 07-17-2012 02:15 AM

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:
Code:

/usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/5.12.3/i486-linux-thread-multi/auto/BDI/DBI.so: undefined symbol: Perl_Istack_sp_ptr
Unfortunately, I don't know where to start looking for a solution. Any pointers would be most helpful.

Thanks, BG4.

pan64 07-17-2012 02:21 AM

try a clean install instead of an update

XGizzmo 07-17-2012 05:25 AM

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?

bg4 07-17-2012 04:58 PM

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.

CTM 07-17-2012 05:57 PM

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.

Code:

# cpanp -i DBI
will fix you.

bg4 07-21-2012 01:42 AM

Solved
 
Thank you CTM,

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

BG4

dsbx 08-25-2017 02:10 PM

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?

zakame 08-25-2017 08:45 PM

Quote:

Originally Posted by dsbx (Post 5751943)
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

dsbx 08-29-2017 04:24 PM

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.

zakame 08-30-2017 02:43 AM

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.)

ponce 08-30-2017 02:46 AM

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

zakame 08-30-2017 03:30 AM

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

ponce 08-30-2017 03:51 AM

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 ;)

dsbx 08-30-2017 06:23 AM

Quote:

Originally Posted by ponce (Post 5753606)
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

ponce 08-30-2017 07:42 AM

Quote:

Originally Posted by dsbx (Post 5753650)
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.

can you provide more info on the "error"?


All times are GMT -5. The time now is 04:07 PM.