I've attached the full build log. I saw this referenced (and closed) in another bug that the filer closed as he couldn't reproduce on a slightly different version. (bug #43297) This was done on a mostly pristine system, started with 2004.0 stage3 ppc Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.50-r1 (default-ppc-2004.0, gcc-3.2.3, glibc-2.3.2-r9, 2.6.3-ben2) ================================================================= System uname: 2.6.3-ben2 ppc 740/750 Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.8 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=powerpc" CHOST="powerpc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2 /share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -mcpu=powerpc" DISTDIR="/usr/portage/distfiles" FEATURES="ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/d istributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X arts berkdb cups dvd esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib jpe g kde libwww mitshm motif mozilla nls oggvorbis opengl oss pam perl png ppc pyth on qt readline sdl slang ssl tcpd truetype xv"
Created attachment 27892 [details] Vim full build log with errors (long)
Looks like a dupe of bug #43297... *** This bug has been marked as a duplicate of 43297 ***
Re-opening the bug. Please re-read the first post, as I stated that it is a duplicate of the bug you stated (which was closed by the user and not resolved as it just worked for him when he tried again). I thought it made more sense to file a new one than to try and re-open an old bug on a different version of vim (his was r5 I think). This problem exists, if you need further info please let me know as I've reproduced it 3 times in a row ;) Also I had thought I marked this Gentoo ppc (it happened on my ppc machine). Can anyone else on ppc reproduce this? Thanks
yes, I had the same problem while building the GRP for 2004.0. If I'm not mistaken the solution was to remerge ruby before emerging vim. lu_zero pointed me to the solution. cc'ing him
ahh ok, thanks. I'll see what lu has to say here as well, if we can help isolate the problem that machine doesn't need vim on it that badly yet :)
The build log you provided was for 6.2-r3. Does this still happen for 6.2-r7 which is marked stable on ppc?
Unable to reproduce it with -r7.
Pieter: Did you try from a clean stage3 chroot? This is where I had the issue in the first place The request for more info was followed up 7 minutes later by the bug closing as resolved, do you want input from me or not?
Haha, unpacking a stage3, setting it up (resolv.conf, bind mounting proc/dev/portage), chrooting into it and emerging vim and all its dependencies takes about 3 minutes on my dual G5. That leaves 4 minutes to write a single line saying -r7 fixes your problem. Which is btw something I already knew, because of building new sets of GRP every two days. Attached is the output of a screen session which shows emerging vim and all its dependencies takes exactly 2m59sec. I just happened to be fast for once :-)
Created attachment 28385 [details] screen log - showing -r7 builds fine attached screen log
-r3 builds just fine too on in the same ppc 2004.0 stage3 chroot (screen log attached). I'll retry using the exact same USE flag configuration.
Created attachment 28386 [details] screen log - showing -r3 builds fine
Using the exact same USE setting, CFLAGS, and ACCEPT_KEYWORD. Vim -r3 builds correctly too. Tested -r7 with the same use flag setting. Works just fine. Screen log attached. This is in a 2004.0 ppc stage3 chroot, running the exact same kernel as the user. Did I mention vim even compiles with 2.6 headers on ppc?
Created attachment 28387 [details] Same use flag setting - both -r3 and -r7 compile
Would you like me to upload a binary?
My, but you are an ass. Sorry I tried to help out here, I won't be doing so again. Can you please GET OVER IT and leave me alone??!? Is that really that much to ask? I was trying to report a bug and this is what I get? Are you now going to threaten to fly to Toronto and kick me in the face again? When I spouted off like this to users on bugzilla I got kicked off the project, so I don't know how you rate. It's devs like YOU that give gentoo a bad name.
I have cc'ed devrel on this bug. These people fix developer behaviour bugs (if any :-) ) Imho this is no longer a vim bug since the ppc team cannot possibly reproduce the bug, there's also no need to keep this open as a ppc bug, since it obviously works on ppc now (and that was what needed to be tested). There's a vim binary on the ppc GRP cd, If you want I can make this binary available for download on the web.
assigning to devrel (recruiters) -- we should set up a separate alias
Sorry to be late in commenting about that bug the issue seems like a conflict with some header, I cannot reproduce it here and as Pieter, maybe a bit overzeausly, stated seems an isolated problem I'm about to unpack the vim.h from that revision to track it a bit more but will take time since I'm on a g4 and I have other issue to address, please wait a bit more.
It looks very much like the kernel header bugs that showed up with respect to kde sometime ago. Try an uptodate linux-headers.
Steps to reproduce (works _every_ time on 2 ppc machines I have here): setup a fresh chroot with the 2004.0 stage3 (untar, mount -o bind /proc chroot/proc, mount -o bind /usr/portage chroot/usr/portage) USE="-ruby" emerge vim This gave me same result on -r3 and -r7 (the parse errors).
Paul: I have the latest linux-headers marked stable on ppc (2.4.22 which are kind of old and crusty), but thanks for the suggestion. It really seems to me like vim just doesn't want to build without ruby although it says that it can
I had the same problem on x86 (without reading all the details). Following through all the links, the thing that fixed it for me is mentioned in http://bugs.gentoo.org/show_bug.cgi?id=39794 All I had to do was to run ldconfig and then vim built fine.
ldconfig did fix up the problems. Seems the problem is with the stage(s) being distributed and not vim itself. Someone should take this up with the PPC team as I will not be. I'll leave this bug open to do with what you guys want. Hint to any PPC takers: run ldconfig in --verbose mode on the distributed stages to see why this is problematic. Seems like it's not just a PPC problem (I suspect the catalyst process but what do I know).
The documentation says to run env-update after chrooting, this should have run ldconfig. I did run env-update after chroot, which is probably why I couldn't reproduce the issue. According to the manpage, Portage also runs env-update after each package merge. I guess that it doesn't run ldconfig every time. We should look into that. zhen: catalyst GRP target behaves correctly (building vim as grp works just fine), the livecd-stage1 target however doesn't (fails to build vim). I guess env-update is missing from the livecd-stage1 chroot.
I did run env-update when I chrooted (all 8 times I've reproduced this now). I used the stage3, not the stage1
Just for clarity: 'livecd-stage1' and 'grp' are two catalyst targets. Both take a stage3 and emerge things in the chroot. I have vim listed as a package that should be build in both fot the livecds live-environment and for the GRP packages cd. The vim issue can be reproduced with 'livecd-stage1' but not with the grp target. That's a small bug in catalyst, but it might help us find a solution to this problem. But like I said, neither catalyst nor the ppc team is at fault here because it is "probably" an env-update or portage bug (where env-update does not run ldconfig correctly). According to the env-update manpage env-update should run ldconfig. Env-update is run after each emerge install. Whether you used a ppc or an x86 stage shouldn't matter, the bug is reproduceable on all architectures.
Bug no longer relevant, closing.
