Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/26/05, Harry Putnam [EMAIL PROTECTED] wrote: Harry Putnam [EMAIL PROTECTED] writes: Richard Fish [EMAIL PROTECTED] writes: conftest echo works root # ./conftest echo works works Seems to have worked as expected. Looking at qpkg -v -I|grep gcc root # qpkg -v -I|grep gcc sys-devel/gcc-3.3.5.20050130-r1 * sys-devel/gcc-3.4.4-r1 * sys-devel/gcc-config-1.3.12-r4 * Is it normal to have 2 versions installed? Yes. Gcc is slotted, so it is normal to have more than one version installed. Would a more recent version be likely to solve the cross-compiler problem? 3.4.4-r1 is the most recent version available for ~x86. The only thing I can think of that might fix it would be an emerge -e system. But could you post the first 200 lines of /var/tmp/portage/mod_php-4.4.0/work/php-4.4.0/config.log? Maybe there is an answer there... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/26/05, Harry Putnam [EMAIL PROTECTED] wrote: Richard Fish [EMAIL PROTECTED] writes: /var/tmp/portage/mod_php-4.4.0/work/php-4.4.0/config.log Some stuff after 200 lines looks like it might be pertinent so posting 250 lines. I hope you see something: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:1656: checking host system type configure:1756: checking for gcc configure:1869: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works configure:1885: gcc -o conftest -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib conftest.c -lxmlparse -lxmltok 15 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/ld: warning: libmysqlclient.so.12, needed by /usr/X11R6/lib/libxmlparse.so, not found (try using -rpath or -rpath-link) Ah, here is a problem. A broken library dependancy. I don't know what package libxmlparse is a part of, but it is linked against libmysqlcliient.so.12, which does not exist now. Run equery belongs /usr/lib/libxmlparse.so, and rebuild (with emerge --oneshot pkg) whatever package that is a part of. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/26/05, Harry Putnam [EMAIL PROTECTED] wrote: Richard Fish [EMAIL PROTECTED] writes: Is it normal to have 2 versions installed? Yes. Gcc is slotted, so it is normal to have more than one version installed. Do I need two versions?. Technically, no. But this is where I get a bit paranoid, because if you break the libstdc++ dynamic linking, you cripple the system (including portage!). So, I would only prune the old versions of gcc after doing a emerge -e world to rebuild *everything* with the new gcc. Oh, and a fix_libtool_files.sh also... And making a good backup... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: First let me add that (mjpegtools-1.6.2-r3) isn't even installed: root # qpkg -v -I |grep mjpegtools media-video/mjpegtools-1.8.0-r1 * equery depends mjpegtools [ Searching for packages depending on mjpegtools... ] media-video/transcode-0.6.14-r2 media-video/cinelerra-cvs-20050801 both are installed here: # qpkg -v -I |grep 'transcode\|cinelerra' media-video/transcode-0.6.14-r2 * media-video/cinelerra-cvs-20050801 * This seems odd: Runtime Dependencies transcode-0.6.14-r2 media-libs/libexif media-libs/netpbm | = media-video/ffmpeg - 0.4.9_pre1 a52 = media-libs/a52dec - 0.7.4 avi = media-video/avifile - 0.7.41.20041001 dv = media-libs/libdv - 0.99 dvdread = media-libs/libdvdread - 0.9.0 encode = media-sound/lame - 3.93 fame = media-libs/libfame - 0.9.1 gtk = x11-libs/gtk+ - 1.2* imagemagick = media-gfx/imagemagick - 5.5.6.0 jpeg media-libs/jpeg lzo = dev-libs/lzo - 1.08 mjpeg = media-video/mjpegtools - 1.6.2-r3 mpeg media-libs/libmpeg3 ogg media-libs/libogg pvm = sys-cluster/pvm - 3.4 quicktime = media-libs/libquicktime - 0.9.3 sdl media-libs/libsdl theora media-libs/libtheora truetype = media-libs/freetype - 2 vorbis media-libs/libvorbis xvid = media-libs/xvid - 1.0.2 X virtual/x11 Runtime Dependencies cinelerra-cvs-20050801 media-libs/faad2 media-libs/libdv | = media-libs/libogg - 1.0 media-libs/libpng | = media-libs/libtheora - 1.0_alpha4-r1 | = media-libs/libvorbis - 1.0.1-r2 | = media-libs/openexr - 1.2.1 | = media-sound/esound - 0.2.34 ! media-video/cinelerra - ! media-video/cinelerra - media-video/mjpegtools | = sys-libs/libavc1394 - 0.4.1 |= sys-libs/libraw1394 - 0.9.0 virtual/x11 What seems odd to me is that neither of these two programs depends on that specific version of mpegtools. Transcode will take that version or above, cinelerra doesn't care. And, since you have a greater version installed, there seems to be no reason that revdep-rebuild should be trying to install an older version in this way. The highest likelihood is that-- as previously suggested-- you're running an old output from revdep-rebuild -p (when this version was the installed version of mjpegtools), and did not delete the old output files and re-run revdep-rebuild -p to get a new prospective rebuild list. You might want to check your /root/ folder and see what the dates on those .revdep-rebuild files is. If they aren't from a recent time, remove them, and run revdep-rebuild (-p) again. Alternatively (hacky solution), try re-emerging cinelerra and transcode again (to retrain them in where their dependent files are and what version they are). Even more hackily, remove mjpegtools totaly (unmerge), then do an emerge -uaDtv world, and let it get pulled back in as a dependency of the two packages that need it. That ought to straighten everything out. But probably you're just using old revdep-rebuild output, and the easiest solution would be to delete those files so that revdep-rebuild can update itself with the current state of your system. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: Richard Fish [EMAIL PROTECTED] writes: (Including Richard in reply as well) Nagatoro [EMAIL PROTECTED] writes: [...] Assigning files to ebuilds... using existing /root/.revdep-rebuild.4_ebuilds. Evaluating package order... using existing Nagatoro replied: ^^^using existing^^^ means that you are using the results from an older run of revdep-rebuild. First remove all .revdep* files and the run it again and see if you find the same errors. Harry responds: Ack, yes of course and it even warns you about that However having removed them I still get a huge list of stuff listed as BROKEN Yes, well, that's what revdep-rebuild does-- finds broken stuff. It's doing its job-- what's the problem with that? One of the first involves the same mjpeg package that isn't even installed: broken /usr/bin/cinelerra (requires libmjpegutils-1.6.so.0) U--- why do you feel that this is the same package that isn't even installed? You said that you have libmjpegutils installed, just not the same version that was attempting to be rebuilt before 1.8.0 installed, rather than the 1.6.2-r3 that was attempting to be rebuilt). eix mjpegtools * media-video/mjpegtools Available versions: 1.6.2-r4 ~1.8.0 ~1.8.0-r1 Installed: 1.6.2-r4 Homepage:http://mjpeg.sourceforge.net/ Description: Tools for MJPEG video equery files media-video/mjpegtools [ Searching for packages matching media-video/mjpegtools... ] * Contents of media-video/mjpegtools-1.6.2-r4: /usr/lib/libmjpegutils-1.6.so.0 - libmjpegutils-1.6.so.0.2.2 Now, obviously this is not the same version of mjpegtools that you have, but what it indicates is that the file libmjpegutils-1.6.so.0 is a symlink to whatever version of the actual library is installed by the package. I rather expect that what would happen if I were to upgrade this package is that the symlink itself would remain, but the target of the symlink would change. If this is in fact the case, two points: 1: your symlink seems to be broken; 2: the error you have listed does not say anything about what version of mjpegtools is installed or broken, so revdep-rebuild is not necessarily talking about the same version as previously, But better to go to the source: == Full output of revdep-rebuild (minus all config make stuff [sorry about control chars I forgot to use -nc but have removed some]): Note it doesn't appear to say what pkg actually failed: Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild.. emerge --oneshot =dev-php/mod_php-4.4.0 =dev-php/php-4.4.0 =media-libs/imlib-1.9.14-r3 =kde-base/kdegraphics-3.4.1-r1 =media-gfx/imagemagick-6.2.5.4 =media-libs/libdv-0.102 =media-video/avifile-0.7.41.20041001-r1 =media-video/cinelerra-cvs-20050801 =media-video/transcode-0.6.14-r2 =net-libs/libwww-5.4.0-r3 ^G.^G.^G.^G.^G.^G.^G.^G.^G.^G. --8 [big snip] you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild So apparently the rebuild failed. But first of all, I don't see mjpegtools being rebuilt in this list, so that is not the problem apparently (the problem is not that mjpegtools is not installed, but that the programs that depend on it are not linked against it, which is what revdep-rebuild is trying to fix by re-emerging them); ... and second of all, which package failed to emerge and why? Meaning, what was the error in whichever package failed to emerge? Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: It turn out that using old revdep output was not the problem. See just posted output in response to Nagatoro. Actually it was. Notice that revdep-rebuild is no longer trying to rebuild mjpegtools, but those things that depend upon mjpegtools (along with other broken packages). So, what package is actually failing to merge, and what is the error message that is being given? -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: Harry Putnam [EMAIL PROTECTED] writes: Oh crap.. overzealous snippage caused me to leave out the main stuff: I seem to have taken a moron pill this morning please see full output of revdep-rebuild in a few minutes at: http://www.jtan.com/~reader/vu_txt/display.shtml (in 5 min or so) Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works... yes checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
Harry Putnam schreef: I still don't see the actual error there and it was the output of: revdep-rebuild -nc 21|tee revdep.log revdep.log is what I posted online. Richard Fish replied with the specific issue about half an hour ago: Richard Fish schreef: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) works... yes checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a cross-compiler... yes The problem occurs with the very first compile configure: error: can not run test program while cross compiling ...done! | emerge (1 of 10) dev-php/mod_php-4.4.0 to / ... so the problem is definitely somewhere in your toolchain, rather than anything to do with either revdep-rebuild or the specific programs attempting to be rebuilt. Posting emerge info is a good starting point to troubleshoot this (unless you already happen to know why this is occurring, that's also possible). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote: Richard Fish [EMAIL PROTECTED] writes: Ok, now we are going to need to see the output of emerge --info, because for some reason your toolchain thinks it is cross-compiling: There appears to be some confusion in that output as to what USE flags are in force. ACCEPT_KEYWORDS=x86 ~x86 I guess the last is what is used? I have in /etc/make.conf ACCEPT_KEYWORDS=~x86 This is because a few -u worls back (2 I think) I foolishly ran ACCEPT_KEYWORDS='~x86' emerges -v -u -D world Well, the only way ~x86 could have been added to make.conf was if it was edited directly. Running with ACCEPT_KEYWORDS in the environment would not have changed it. Having --info report both x86 and ~x86 is normal...it means both stable and testing packages are allowed. And it seems more trouble to back out of that now than to just try to see if I (with help) can stay on top of it. Well, it isn't terribly difficult to switch back to stable. Just remove the ~x86 keyword from make.conf and emerge -DNuv world. The worst case is when you have some testing package merged for which there is no stable version, in which case you either have to unmerge the package or add the appropriate entry to /etc/portage/package.keywords. And of course, don't forget etc-update afterwards. Anyway, on the to the problem at hand: emerge -n -v --info 21|tee emergeInfo.log Gentoo Base System version 1.6.13 Hmm, I would have expected something more recent for ~x86. What does emerge -vp sys-apps/baselayout report? Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r3, 2.6.14-gentoo-r2 i686) Ok, run gcc-config -l. You should see an entry for i686-pc-linux-gnu-3.4.4. If so, run gcc-config i686-pc-linux-gnu-3.4.4 Then try the revdep-rebuld again. Everything else looks sane. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote:
Harry Putnam [EMAIL PROTECTED] writes:
[...]
checking whether the C compiler (gcc -O2 -march=pentium4
-fomit-frame-pointer -L/usr/X11R6/lib -ltiff -L/usr/lib) is a
cross-compiler... yes
Still thinks its a cross-compiler... what does that mean anyway?
Well, generally, it means that you are compiling for a different
architecture than what you are running. For example, it is possible
to compile for AMD64 CPUs from a P4 host, or vice-versa. However,
since you are not doing that, it means your toolchain is broken in
some way.
The way autoconf (the ./configure script) checks for this is that it
compiles a very simple program. This program is:
#line 1880 configure
#include confdefs.h
main(){return(0);}
It then compiles this program. If the program compiles, configure
decides that gcc works. If the program doesn't run, it decides that
you are cross compiling. So, let's try this manually.
Save the above lines to a file, call it conftest.c. The build it with
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff
-L/usr/lib -o conftest conftest.c
If the compile complets without error, try running the program with:
conftest echo works
-Richard
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Harry Putnam [EMAIL PROTECTED] wrote:
Richard Fish [EMAIL PROTECTED] writes:
#line 1880 configure
#include confdefs.h
main(){return(0);}
It then compiles this program. If the program compiles, configure
decides that gcc works. If the program doesn't run, it decides that
you are cross compiling. So, let's try this manually.
Save the above lines to a file, call it conftest.c. The build it with
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib -ltiff
-L/usr/lib -o conftest conftest.c
gcc -O2 -march=pentium4 -fomit-frame-pointer -L/usr/X11R6/lib \
-ltiff -L/usr/lib -o conftest conftest.c
configure:1880:22: confdefs.h: No such file or directory
Just complains about not finding confdefs.h.
Sorry, my fault. Confdefs.h is generated by the configure script, and
doesn't matter for this case. Just remove the include from the file.
-Richard
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/24/05, Harry Putnam [EMAIL PROTECTED] wrote: Richard Fish [EMAIL PROTECTED] writes: My guess is 'emerge -u --oneshot mjpegtools' will fix the problem. No, it didn't change a thing. But there was some output at the end that might mean something: [...] * Please upgrade your package (mjpegtools-1.6.2-r3) to use toolchain-funcs.eclass Interesting. All 3 builds currently in portage (1.6.2-r4, 1.8.0, and 1.8.0-r1) use toolchain-funcs already. What is the result of ls /usr/portage/media-video/jpegtools/*.ebuild and equery depends mjpegtools -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: How serious is revdep-rebuild failure
On 11/25/05, Richard Fish [EMAIL PROTECTED] wrote: What is the result of ls /usr/portage/media-video/jpegtools/*.ebuild and equery depends mjpegtools Also, do you have anything for mjpegtools in /etc/portage/package.mask? -Richard -- gentoo-user@gentoo.org mailing list
