On Wed, Sep 21, 2011 at 09:17:40AM -0400, Robert P. J. Day wrote: > 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.
Then they shouldn't be picking up other stuff on your system. They should be 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 They shouldn't, but it seems that they do. > 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. 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. You *may* be able to get away with explicitly setting @INC, perhaps in $PERL5OPT. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/