checking for libjpeg6b... no checking for libjpeg... -ljpeg checking for perl... /usr/bin/perl checking for Qt... libraries /usr/qt/3/lib, headers /usr/qt/3/include using -mt checking for moc... /usr/qt/3/bin/moc checking for uic... /usr/qt/3/bin/uic checking whether uic supports -L ... yes checking whether uic supports -nounload ... yes checking if Qt needs -ljpeg... no checking for rpath... yes checking for KDE... configure: error: in the prefix, you've chosen, are no KDE headers installed. This will fail. So, check this please and use another prefix! !!! ERROR: media-video/kplayer-0.5.3 failed. !!! Function kde_src_compile, Line 2183, Exitcode 1 !!! died running ./configure, kde_src_compile:configure !!! If you need support, post the topmost build error, NOT this status message. Portage 1.589-cvs (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.12-rc3-gentoo i686) ================================================================= System uname: 2.6.12-rc3-gentoo i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.11 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 12 2005, 22:11:27)] distcc: No such file or directory [disabled] ccache: No such file or directory [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.3, 1.1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -ftracer -mfpmath=387" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -ftracer -mfpmath=387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache cvs distlocks sandbox sfperms sign strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/" LANG="en_GB.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib acpi alsa avi bash-completion beepmp bitmap-fonts cdr cups curl directfb dvd eds emboss fbcon flac foomaticdb fortran gcj gd ggi gif gnome gpm gstreamer gtk gtk2 hal howl imagemagick imlib java jpeg libg++ libwww mad mmx mono mozilla moznocompose moznoirc moznomail mp3 mpeg ncurses nomotif nptl ogg oggvorbis opengl pdflib perl png qt quicktime readline real sandbox sdl slang sqlite sse ssl tcpd tiff truetype truetype-fonts type1-fonts userlocales vorbis xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS Config files: /etc/make.conf, /etc/portage/bashrc, /etc/portage/mirrors, /etc/portage/package.mask, /etc/portage/package.unmask
Created attachment 58354 [details] config.loh
Works fine here. Do you have any kde eclass in a overlay, or have any hint about why kde-functions.eclass does not set the KDEDIR environment variable?
Daniel: Could you tell us what the value of KDEDIR in the kplayer environment file is?
Sorry for the delay. Yes, KDEDIR is set correctly by kde-functions.eclass (/usr/kde/3.4). I can't explain why, but the upcoming diff fixes it.
Created attachment 61659 [details, diff] kde.eclass fix
So the problem is that with portage-cvs, if there's an 'export FOO' in global scope in an ebuild, then portage makes FOO available in src_compile just as a bash variable, and not as a variable exported in the environment?
I'm not exactly sure. But I have a general idea. With current stable portage, the behaviour goes something like: Source entire ebuild and eclass Source entire ebuild and eclass pkg_setup Source entire ebuild and eclass src_unpack Source entire ebuild and eclass src_compile Source entire ebuild and eclass src_install etc. portage-cvs does it in a more sensible manner, i.e. only sources once (I guess). But I'm really not sure of the details. I know that it saves the environment and sends it over a socket at some point, perhaps it is forgetting which variables have been exported.
So is this definitely a portage issue? Should it be reassigned to dev-portage@? Personally I see un-exporting variables as a bug, if only because I'd expect more than a few existing ebuilds/eclasses to break. But this is just IMHO. Daniel, are you a portage-dev member? If not can a member say what's the correct behavior and whether we are required to change anything?
I'm not a portage developer and I can't explain the behaviour. I've asked ferringb to take a look.
The next portage version is more picky about the environment, means exports do not cross eclasses anymore. Fixing this is easily done by taking the export statements from kde-functions.eclass to kde.eclass. I haven't done it yet, because I planned to read the new portage code before. I just don't have enough time and portage 2.1 is not even on my prority list before I see a message in gentoo-dev that it will reach the tree.
*** Bug 92952 has been marked as a duplicate of this bug. ***
> The next portage version is more picky about the environment, means exports > do not cross eclasses anymore. Do exports still cross from eclasses to ebuilds? If not, a lot of changes will be needed since ebuilds rely on variables being exported by eclasses. > Fixing this is easily done by taking the > export statements from kde-functions.eclass to kde.eclass. Copying them, rather, since some ebuilds use kde-functions without kde.
*** Bug 102896 has been marked as a duplicate of this bug. ***
> The next portage version is more picky about the environment, means exports > do not cross eclasses anymore. Eh? Yes they do :) > Do exports still cross from eclasses to ebuilds? > If not, a lot of changes will be needed since ebuilds rely on variables being > exported by eclasses. Yes, they do. > Fixing this is easily done by taking the > export statements from kde-functions.eclass to kde.eclass. > Copying them, rather, since some ebuilds use kde-functions without kde. Shouldn't matter. The env modifications y'all are talking about are essentially loading, and reinstating the env (export included) between phases, instead of re-sourcing the ebuild. If it's failing, either bug in the source, or bug in portage. Anyone who can trigger this, run with DEBUGGING=1 DEBUG_FILTER=0 emerge blah and my bashrc http://dev.gentoo.org/~ferringb/bashrc When it bails, tarball up ${T} and attach it here. That's a full dump per phase, so any screwups will be clear. The only possibility I can think of, is init_environ's dump/restore of env (for a protected env import of /etc/profile.env) is at fault, since it explicitly drops attributes for the saved. That said, if the attribute is marked for export, on the reload of the dumped env it'll just reset values- will not reset attributes (meaning exported stays exported).
(In reply to comment #14) > That said, if the attribute is marked for export, on the reload of the dumped > env it'll just reset values- will not reset attributes (meaning exported stays > exported). kde-functions.eclass exports KDEDIR and kde.eclass (inheriting the former) accesses the value...
Doesn't matter. Bash blows about lexical scoping (effectively there is none, aside from when you do local, which screws up special vars). As stated, dump of envs please. If it's exported once, it *should* be still available with those attributes. The only exception to this is in reloading env's from .51, which is not the case here (you're not unmerging nor binpkg merging).
Currently running portage-2.1_pre3-r1 and the problem is no more - kplayer emerged just fine. Thanks!
