After recent emerge --update world, perl scripts using RRDs fail: RRDs object version 1.000391 does not match bootstrap parameter 1.000351 at /usr/lib/perl5/5.8.0/i686-linux/DynaLoader.pm line 249. Compilation failed in require at /usr/local/bin/logger_update.pl line 3. BEGIN failed--compilation aborted at /usr/local/bin/logger_update.pl line 3. Correct perl update proceedure has been followed, and I ran the script as well, to no help.
Dan, rrdtool compiles and installs fine over here. A few questions. Did you run the recommened libperl_rebuilder after upgrading perl as it states in the einfo at the end of the perl install? This should have caught rrdtool and reinstalled it (which appears to be your problem). What is the third line in your script, logger_update, and what provided that? Can you paste the top portion of that script in here, especially any require/use fields?
Yes, I ran the perl rebuilder afterwards as stated. However, a cursory examination of emerge.log showed that rrdtool was not recompiled.. I could be wrong, however. I unmerged and remerged rrdtool as well, with no change in symptom. The script is something I wrote to add lm_sensors data into a RRD using cron. top three lines: #!/usr/bin/perl -w use strict; use RRDs; Those are the only use/require statements. Any other ideas?
Tons of ideas :) Patience is the only thing we may run out of. First shot - does this work on the command line: perl -e "use RRDs;" - if it works, you should get, well, nothing back. If it doesn't work, then the problem is isolated to your RRDs install. If that is the case, we should check to see when the deps for RRDs were installed. Which version of libgd are you using? I don't want to infringe on your script, but if the perl -e line comes back ok, may need to ask if I can take a look at your script. I can send you my gpg key if you would rather encrypt it (just being cautious, don't want to seem like I'm "stealing" your source). Let me know how you want to proceed, plus the info above. Thanks!
dpn@juniper:~$ perl -e "use RRDs;" RRDs object version 1.000391 does not match bootstrap parameter 1.000351 at /usr/lib/perl5/5.8.0/i686-linux/DynaLoader.pm line 249. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I should have thought to try that before, however, I hadn't considered the possibility of a problem in the script. Current version of libgd installed is: media-libs/libgd-1.8.3-r5 If you want to see the script, you're welcome to take a look. However, from the earlier pasted response to perl -e, I don't think it is the problem.
Hmmm, looks like I'm going to have to find someone more knowledge about RRDs. Namely, I don't know more than it compiles, installs some perl modules, etc., and that over here those appear to be fine (perl -e does as expected). Also - sorry about the rebuiler question, I missed the part in your original post where you said "ran the script". A question I should have asked to begin with, though the @INC statement would indicate not - did you compile perl with threads? If so, there was a tweak to the ebuild yesterday evening EST time that corrected a bug for -threaded installs. I will keep poking at it. In the meantime, can you post the contents of /var/db/pkg/net-analyzer/rrdtool-1.0.39/CONTENTS? That will tell us exactly where everything was installed to and help eliminate a few other items real fast. Thanks, Mike
Created attachment 7146 [details] /var/db/pkg/net-analyzer/rrdtool-1.0.39/CONTENTS
dpn@juniper:~$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.19-gentoo-r10, archname=i686-linux uname='linux juniper.nlocal.net 2.4.19-gentoo-r10 #1 wed jan 1 20:47:34 est 2003 i686 amd athlon(tm) xp 2000+ authenticamd gnulinux ' config_args='-des -Darchname=i686-linux -Dcc=gcc -Dprefix=/usr - Dvendorprefix=/usr -Dsiteprefixx=/usr -Dlocincpth= -Doptimize=-mcpu=athlon- xp -O3 -pipe -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Dman3ext=3pm - Dcf_by=Gentoo -Ud_csh -Di_gdbm -Di_db -Di_ndbm' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL5 -fno-strict-aliasing -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64', optimize='-mcpu=athlon-xp -O3 -pipe', cppflags='-DPERL5 -DPERL5 -fno-strict-aliasing' ccversion='', gccversion='3.2.1', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.3.1.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Jan 8 2003 14:33:25 @INC: /usr/lib/perl5/5.8.0/i686-linux /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686-linux /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i686-linux /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . I presume that indicates I have not compiled with threads, right? threads=undef? I know a good bit about perl, but threads isn't something I've dabbled in. The CONTENTS file is attached.
Threads required you to "interfere" with the ebuild and do a USE="threads" emerge perl - so no, your good. I only ask because there are problems with threaded perls - really only available for the die hard perl folks who couldn't live without them. The good news is I see the proble. Looking at the Contents file, then looking over at my own installation, I see that most of the install went into /usr/lib/perl5/blahnblah, good, but a few files, went into /usr/lib/perl/ <---eeek! The bad news is it is going to take me a little while to get the patch in for this. I wanted to post so that you knew that I saw the problem and will get to it, but that it will be later today before I have the fix in (or figure out the fix, though it should be simple enough). Thanks, Mike
Thanks a bunch. No rush on the fix.. my rrdtool graphs (http://juniper.isomerica.net/sysgraph/) are mainly an experiment/toy :)
Dan, OK, I had some ideas. Played around. Even went on a tangent to look at the newer libgd, the newer (one version up) of rrdtools, but I'm still at the same spot - unable to duplicate your problem. Even asked a few other devs to emerge it, ditto, we all can use it fine (yeah, dev conspiracy if you ask me). So here's a final stab. In /usr/lib, can you do a find ./ -name "RRDs.so" - would like to see that it only shows up in two places, the bogus /usr/lib/perl/ (harmless, though it needs to be removed in the build - the packages are properly installed elsewhere) and /usr/lib/perl5/site_perl/5.8.0/i686-linux/auto/RRDs/ and making. If that works, then the only other thing I can think to check is doing an ldd on /usr/lib/perl5/site_perl/5.8.0/i686-linux/auto/RRDs/RRDs.so and making sure everything comes back found.
well, maybe not entirely the last straw. The last straw would be to offer to give you a binary package of the install (compile it over here on one of my 1.4 boxes, perhaps my 686) and send that to you. I can do that, will do it willingly, but would like to see this resolved short of that since this suggests other problems.
root@juniper:/usr/lib# find ./ -name "RRDs.so" ./perl/auto/RRDs/RRDs.so ./perl5/site_perl/5.8.0/i686-linux-thread-multi/auto/RRDs/RRDs.so
Dan, Have you upgraded perl more than once? Or, is this not your first perl 5.8 install? You have conflicting paths below - one set points to a non threaded perl, but the location of that RRDs.so is in a threaded perl directory.
Its quite possible. A while ago, my perl got updated to 5.8.0 during a -- update world, I presume because it had been added but not masked yet, or something silly. Bad timing. A later world update reverted perl to 5.6.0. Never once did I explicitly specify any options, however.
I had some tragic accidents in my early days. This is the payback. Threading was initially enabled in that ebuild until we/I realized how utterly bad it was for some applications. That is what is throwing off your install of rrdtools. Let me see if I can think of "nice" way to get you your working perl without losing anything. What does emerge -pc perl show? Does it show anything for that last merge of perl 5.8? If so, emerge -c perl may get you going again, lickety split. Otherwise, the only course of actions I can see are to either a) try removing the -thread-multi dir's from your perl 5.8 tree, and seeing if a re-emerge of rrdtools puts that .so (and other files) in the right place, or (last resort that I would suggest) unmerging perl, keep track of anything like rrdtools that placed files in /usr/lib/perl5, remove /usr/lib/perl5, then emerge perl, run the paired down version of the rebuilder located at http://cvs.gentoo.org/~mcummings/perl58.html (there's a link on there for a perl module rebuilder), then rebuilding those apps like rrdtool that place files in /usr/lib/perl5. This last one is an absolute last resort, I'd rather not entertain the notion, but it is an ultimate solution. See if emerge -pc perl shows anything, but hold off on removing perl and starting over (that seems silly).
root@juniper:~# emerge -pc perl >>> These are the packages that I would unmerge: sys-devel/perl selected: none protected: 5.8.0-r8 omitted: none >>> clean: No packages selected for removal. I'm afraid I lost you a bit in your thinking.. What would emerge -c perl do? Remerge it and unlink the original files?
emerge -c cleans out previous installs if you don't have autoclean enabled (or turned off, actually). My hope was that emerge -c perl would emerge a previous version of perl -namely the version that was installed with threading enabled.
whats the next course of action then? manual remove of the threaded directory?
I'd like to take this "slowly" so as to avoid complications. My first recommendation would be to cd /usr/lib/perl5 and do the following: ls -al `find ./ -name "*thread*" -type d` >~/thread_list (those are backticks) find ./ -type f -exec grep -risl "thread" {} \; >~/thread_files That way we have a listing of what was in those directories, and what files (particularly whether Config.pm in CORE) contained thread references. The second list will have false positives - that's to be expected. Even a non- threaded perl does come with threads.pm for manual invocation. If you don't mind posting those files here as attachments, that would be helpful. What I'm looking for is to see what is inside those -thread directories in particular, and whether your primary Config.pm for perl is referencing them. If all that is located inside those thread directories are a few files installed by other apps, we can wipe the dirs immediately, grab what packages provided the errant files (searching the CONTENTS files in /var/db/pkg/*/*/CONTENTS based on the first list) and you will be all set. That is the best possible scenario. Failing that, say for instance that your Config.pm also contains references, we can try removing the directories, fixing your Config.pm, and see if a remerge of rrdtools is fixed. Obviously, I am avoiding the painful but quick (keystroke wise, not time wise) method of fixing this, which is to unmerge perl, remove /usr/lib/perl5, remerge perl, then remerge your installed modules/apps. That will work, but I'd rather suggest doing the least amount of damage as possible in one go. On a side note, I'm sorry about this. This is actually an atypical occurance, and one can say completely my fault. Thank you for your patience, Mike
Created attachment 7168 [details] thread_files Interestingly enough, there seem to be a lot of 5.6.1 references left. Shouldn't these have been deleted when clean wiped them earlier?
Created attachment 7169 [details] thread_list Thanks again. The problem is not that serious.. and the support I'm getting is great. Thanks
The 5.6.1 references that remain are not part of the actual 5.6.1 install. They are left over from modules installed while 5.6.1 was the "active" perl. OK, looking over your list of files in -thread-multi, most(all) of these look like add-on modules, not core modules, which is good. The .ph files can be ignored completely, these are just left over header=>perl conversion files. With these lists in hand, you should be able (or I can ;) ) to identify what the original module was that owned these and simply remove the directory site_perl/5.8.0/i686-linux-thread-multi. Before you do that, a crazy notion that wouldn't break anything. Can you tar up that directory (i.e., just back up site_perl/5.8.0/i686-linux-thread-multi), then remove it and see if RRDs loads? -thread-multi isn't in your @INC, I'm just wondering if perl is hitting it first, seeing an RDDs.so in there, and trying that instead following through to your new install (which the CONTENTS you posted confirms is good). Thanks for saying it's not a rush, but it's annoying to have slightly broken someone's box. :)
Ok, I tarred up the directory /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread- multi and then removed it. Now, trying to load RRDs, it cannot locate it correctly. root@juniper:/usr/lib/perl5/site_perl/5.8.0# perl -e 'use RRDs;' Can't locate loadable object for module RRDs in @INC (@INC contains: /usr/lib/perl5/5.8.0/i686- linux /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686- linux /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/pe rl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i686- linux /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at -e line 1
Believe it or not, that is really progress. It just means you will need to reinstall rrdtools. Now, looking at the list of files in the thread_list attachment, ignoring the .ph files, there are more than a few that will need to be re-emerged. There are two options here. You can rerun the libperl_rebuilder script - it may take a while, but it should get everything back into place. THe other is the old fashioned "what broke? emerge...".
Oh dear.. Well, I ran the update script, which seems to be having a few problems.. gaim, irssi, and vim, gvim, xchat were all unmerged but not remerged (!!). The last line of the output from the script complained that the "livecd" package was no longer in gentoo, and then dumped me back to a prompt. And... root@juniper:~# perl -e 'use RRDs;' RRDs object version 1.000391 does not match bootstrap parameter 1.000351 at /usr/lib/perl5/5.8.0/i686-linux/DynaLoader.pm line 249. However, I don't /think/ the script is working correctly. I've manually remerged the affected applications, and I unmerged the "livecd" package (don't need it, don't really know why I installed it).
Everything seems to be working perfectly after cleanout and remerge. Thanks.
*** Bug 24269 has been marked as a duplicate of this bug. ***
