/usr/lib/perl5/auto/Cwd/Cwd.so: undefined symbol: Perl_Gthr_key_ptr
Robert P. J. Day
argh ... after just skipping the component that was causing the
earlier error, i got further and then this:
perl: symbol lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined
symbol: Perl_Gthr_key_ptr
error: Bad exit status from
/home/rpjday/WindRiver/prj/4.3/vrf/build/perl-Convert-ASN1-0.21/rpm-tmp.42187
(%build)
can someone explain in general why these errors are happening? is
this a mismatch of some kind between the software and the perl
module? is it the software's fault? since i'm getting the ugly
feeling that i may not have seen the last of these so i'd like to know
what's behind these things. thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
lesleyb
>
> argh ... after just skipping the component that was causing the
> earlier error, i got further and then this:
>
> perl: symbol lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined
> symbol: Perl_Gthr_key_ptr
> error: Bad exit status from
> /home/rpjday/WindRiver/prj/4.3/vrf/build/perl-Convert-ASN1-0.21/rpm-tmp.42187
> (%build)
>
which looks like a symbol isn't in the symbol table of the shared object Cwd.so.
> can someone explain in general why these errors are happening? is
> this a mismatch of some kind between the software and the perl
> module? is it the software's fault? since i'm getting the ugly
> feeling that i may not have seen the last of these so i'd like to know
> what's behind these things. thanks.
I would hazard a guess that the software is asking for a Perl_Gthr_key_ptr
function which doesn't exist in the shared object Cwd.so so there may well be a
mismatch between the software requirements and what you have installed.
I suggest you fix the first bug first in case your skipping it is causing this
bug.
Regards
Lesley
Robert P. J. Day
*why* there's that kind of mismatch. i think i mentioned this
already but, *officially*, this build should complete on ubuntu 10.04,
whereas i'm using ubuntu 11.04. so that suggests there's been some
sort of change with one or more perl modules in between that's causing
this grief. but i don't just want to start installing CPAN modules
until i think i understand what that would be fixing.
rday
p.s. is there a way to identify which perl module supplies the
Perl_Gthr_key_ptr symbol? perhaps it's just a dependency issue that
didn't exist in 10.04 but is somehow in 11.04.
Paul Johnson
> On Wed, 21 Sep 2011, 'lesleyb' wrote:
>
> > On Wed, Sep 21, 2011 at 07:24:51AM -0400, Robert P. J. Day wrote:
> > >
> > > perl: symbol lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined
> > > symbol: Perl_Gthr_key_ptr
> > > error: Bad exit status from
> > > /home/rpjday/WindRiver/prj/4.3/vrf/build/perl-Convert-ASN1-0.21/rpm-tmp.42187
> > > (%build)
> i'd love to, but i'm still not clear on how or, more importantly,
> *why* there's that kind of mismatch. i think i mentioned this
> already but, *officially*, this build should complete on ubuntu 10.04,
I don't think you did.
> whereas i'm using ubuntu 11.04. so that suggests there's been some
> sort of change with one or more perl modules in between that's causing
> this grief. but i don't just want to start installing CPAN modules
> until i think i understand what that would be fixing.
>
> rday
>
> p.s. is there a way to identify which perl module supplies the
> Perl_Gthr_key_ptr symbol? perhaps it's just a dependency issue that
> didn't exist in 10.04 but is somehow in 11.04.
That symbol would be defined in libperl.so and is on my system.. It
sounds very much as if this software is not playing nicely. Does it
have its own version of perl, perhaps embedded? Is it messing with
LD_LIBRARY_PATH or something similar?
You could track this down, depending on how much effort you wanted to
put into it. You could start by stracing the whole process. Or you
could locate a correct version of the package. Or you could try
compiling everything up yourself. Or just the source for that package.
Or you could log a bug somewhere. I depends on how much it's worth to
you and how much time and effort you have to invest.
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Robert P. J. Day
> >
> > argh ... after just skipping the component that was causing the
> > earlier error, i got further and then this:
> >
> Probably a good idea to unskip it and fix the problem there first.
>
> > perl: symbol lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined
> > symbol: Perl_Gthr_key_ptr
> > error: Bad exit status from
> > /home/rpjday/WindRiver/prj/4.3/vrf/build/perl-Convert-ASN1-0.21/rpm-tmp.42187
> > (%build)
> >
> which looks like a symbol isn't in the symbol table of the shared object Cwd.so.
tell me if this makes sense.
this project requires all sorts of unpacking and configuring and
compiling and so on, and it comes with a collection of pre-built host
tools -- that is, stuff like perl, python, the autotools and so on.
so you technically don't need to have those tools on your system,
they're available in a directory of the project in binary form, ready
to go and, unless you specify differently, they're the ones that will
be used for all of the processing.
well, if they're valid for a ubuntu 10.04 system, and *my* system is
ubuntu 11.04, then it's entirely possible that they're expecting to
find things like perl modules and symbols in old locations, yes? the
tools that are run to do all this work will, necessarily, be slightly
older versions than the ones that are *installed* on my system, which
strikes me as a perfect recipe for this kind of mismatch.
but there's a possible solution. when one initially configures the
project, one can select that *all* of those host tools will be rebuilt
from scratch. that would obviously take longer and it's not clear it
would solve the problem since they might just be rebuilt with all the
same properties and mismatches.
but that's the situation. argh. thanks for listening.
Robert P. J. Day
> That symbol would be defined in libperl.so and is on my system.. It
> sounds very much as if this software is not playing nicely. Does it
> have its own version of perl, perhaps embedded?
process supplies its own complete set of host tools which, because
they're designed for an earlier version of ubuntu, may not be playing
nicely. i may simply have to do all this on a ubuntu 10.04 system for
which all this was designed.
rday
Paul Johnson
> On Wed, 21 Sep 2011, 'lesleyb' wrote:
>
> > On Wed, Sep 21, 2011 at 07:24:51AM -0400, Robert P. J. Day wrote:
> > >
> > > argh ... after just skipping the component that was causing the
> > > earlier error, i got further and then this:
> > >
> > Probably a good idea to unskip it and fix the problem there first.
> >
> > > perl: symbol lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined
> > > symbol: Perl_Gthr_key_ptr
> > > error: Bad exit status from
> > > /home/rpjday/WindRiver/prj/4.3/vrf/build/perl-Convert-ASN1-0.21/rpm-tmp.42187
> > > (%build)
> > >
> > which looks like a symbol isn't in the symbol table of the shared object Cwd.so.
>
> i might have finally twigged to what the problem is so others can
> tell me if this makes sense.
>
> this project requires all sorts of unpacking and configuring and
> compiling and so on, and it comes with a collection of pre-built host
> tools -- that is, stuff like perl, python, the autotools and so on.
> so you technically don't need to have those tools on your system,
> they're available in a directory of the project in binary form, ready
> to go and, unless you specify differently, they're the ones that will
> be used for all of the processing.
self-contained and configured to only look at their own files.
> well, if they're valid for a ubuntu 10.04 system, and *my* system is
> ubuntu 11.04, then it's entirely possible that they're expecting to
> find things like perl modules and symbols in old locations, yes? the
> tools that are run to do all this work will, necessarily, be slightly
> older versions than the ones that are *installed* on my system, which
> strikes me as a perfect recipe for this kind of mismatch.
>
> but there's a possible solution. when one initially configures the
> project, one can select that *all* of those host tools will be rebuilt
> from scratch. that would obviously take longer and it's not clear it
> would solve the problem since they might just be rebuilt with all the
> same properties and mismatches.
tools somehow. Or get your system tools out of the way somehow.
You *may* be able to get away with explicitly setting @INC, perhaps in
$PERL5OPT.
lesleyb
> On Wed, 21 Sep 2011, 'lesleyb' wrote:
>
> > On Wed, Sep 21, 2011 at 07:24:51AM -0400, Robert P. J. Day wrote:
> > >
> > > argh ... after just skipping the component that was causing the
> > > earlier error, i got further and then this:
> > >
> > Probably a good idea to unskip it and fix the problem there first.
> >
> > function which doesn't exist in the shared object Cwd.so so there may well be a
> > mismatch between the software requirements and what you have installed.
> >
> > I suggest you fix the first bug first in case your skipping it is causing this
> > bug.
>
> i'd love to, but i'm still not clear on how or, more importantly,
> *why* there's that kind of mismatch. i think i mentioned this
> already but, *officially*, this build should complete on ubuntu 10.04,
> whereas i'm using ubuntu 11.04. so that suggests there's been some
> sort of change with one or more perl modules in between that's causing
> this grief. but i don't just want to start installing CPAN modules
> until i think i understand what that would be fixing.
>
this second error. The initial error might better indicate the problem and
fixing it might prevent this second error occurring.
The version of your OS isn't too important, the versions of perl and any
dependencies required are.
> rday
>
> p.s. is there a way to identify which perl module supplies the
> Perl_Gthr_key_ptr symbol? perhaps it's just a dependency issue that
> didn't exist in 10.04 but is somehow in 11.04.
>
Regards
Lesley
Robert P. J. Day
> On Wed, Sep 21, 2011 at 09:17:40AM -0400, Robert P. J. Day wrote:
... snip ...
> > but there's a possible solution. when one initially configures
> > the project, one can select that *all* of those host tools will be
> > rebuilt from scratch. that would obviously take longer and it's
> > not clear it would solve the problem since they might just be
> > rebuilt with all the same properties and mismatches.
>
> You'll probably need to do something like that. Or tell it to use
> your system tools somehow. Or get your system tools out of the way
> somehow.
as a quick first attempt, i'm going to start a new project that
first builds all of the host tools from scratch, then i'll try to
build just one of the offending packages from before with those new
tools.
if that still fails the same way, i'll move on to the next
suggestion. thanks, all, for the help.
rday
p.s. i'm not convinced that rebuilding the host tools will fix things
since, theoretically, they should produce exactly what's already
there. but, hey, that's just the theory.
Robert P. J. Day
> On Wed, Sep 21, 2011 at 08:31:10AM -0400, Robert P. J. Day wrote:
... snip ...
> > p.s. is there a way to identify which perl module supplies the
> > Perl_Gthr_key_ptr symbol? perhaps it's just a dependency issue
> > that didn't exist in 10.04 but is somehow in 11.04.
>
> That symbol would be defined in libperl.so and is on my system.. It
> sounds very much as if this software is not playing nicely. Does it
> have its own version of perl, perhaps embedded? Is it messing with
> LD_LIBRARY_PATH or something similar?
i think i'm close, just need another push. i tried building all my
host tools on this system and the build of "git" still failed with the
same error i've seen before:
/home/rpjday/WindRiver/prj/4.3/vrf_host/host-cross/bin/perl
Makefile.PL
PREFIX='/home/rpjday/WindRiver/prj/4.3/vrf_host/host-cross'
/home/rpjday/WindRiver/prj/4.3/vrf_host/host-cross/bin/perl: symbol
lookup error: /usr/lib/perl5/auto/Cwd/Cwd.so: undefined symbol:
Perl_Gthr_key_ptr
Makefile:41: *** [perl.mak] Error 127
and now another google shows me this:
https://bugs.archlinux.org/task/24575
ah, so the build might just be picking up the totally wrong Cwd.so
file, and a quick "find" shows, yes indeed, there are two of them on
my system:
/usr/lib/perl/5.10.1/auto/Cwd/Cwd.so
/usr/lib/perl5/auto/Cwd/Cwd.so
and checking which packages they belong to:
$ dpkg -S /usr/lib/perl/5.10.1/auto/Cwd/Cwd.so
perl-base: /usr/lib/perl/5.10.1/auto/Cwd/Cwd.so
$ dpkg -S /usr/lib/perl5/auto/Cwd/Cwd.so
libfile-spec-perl: /usr/lib/perl5/auto/Cwd/Cwd.so
$
and it seems clear that the build is picking up the second one of
those. any guesses that the first one is the right one? and what
would be the proper solution here? if i try to remove
libfile-spec-perl, "apt-get" tells me that's the only package that
would go so dependencies wouldn't be an issue.
and why would i have ended up with two packages each containing
Cwd.so? that sounds like a recipe for confusion and badness. but i
don't want to delete anything just yet until i'm feeling more
confident.
rday
lesleyb
to detect the order in which the /usr/lib/perl* directories are searched.
> and why would i have ended up with two packages each containing
> Cwd.so? that sounds like a recipe for confusion and badness. but i
> don't want to delete anything just yet until i'm feeling more
> confident.
sure it is a bug in your system - it would seem the software you are trying to
install isn't very friendly but that could simply be a result of your trying to
tie it into software it doesn't want to use i.e. your Ubuntu installed Perl
versus the perl binary that came with the software.
If the software came with its own binaries and environment then you really
should try building using what it expects to use. I wouldn't declare it a bug
in your system nor a bug in the software. The bug, such as it is, is the way
you are trying to solve the problems you're encountering. Been there, done
that, got the T-shirt ;)
Good luck
Lesley