Checking for C++ header file SDL/SDL_rotozoom.h... no You do not have the SDL/SDL_rotozoom.h headers installed. Exiting. * ERROR: games-sports/vdrift-20120722::gentoo failed (compile phase): * escons failed. * * Call stack: ----------------------------------------------------------------- This is an unstable amd64 chroot image (named plasma-abi32+64_20170216-195507) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-5.4.0 * llvm-config: 3.9.1 Available Python interpreters, in order of preference: [1] python3.4 [2] python3.5 (fallback) [3] python2.7 (fallback) [4] jython2.7 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 7.2.6.8 [icedtea-bin-7] 2) IcedTea JDK 3.3.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-7 system-vm [2] icedtea-bin-8
Created attachment 465230 [details] emerge-info.txt
Created attachment 465232 [details] config.log.tbz2
Created attachment 465234 [details] emerge-history.txt
Created attachment 465236 [details] environment
Created attachment 465238 [details] etc.portage.tbz2
Created attachment 465240 [details] games-sports:vdrift-20120722:20170226-054827.log
Relevant part of the config.log: In file included from .sconf_temp/conftest_4.cpp:2:0: /usr/include/SDL/SDL_rotozoom.h:44:17: fatal error: SDL.h: No such file or directory compilation terminated. scons: Configure: no It looks like SDL_rotozoom.h (part of media-libs/sdl-gfx) expects /usr/include/SDL to be in the include path. Whether that is a valid expectation or not I'm not sure, so maybe it's that header that needs to be fixed? I see SDL_image.h at least includes "SDL.h" instead of <SDL.h>.
Non-maintainer major version bump = you get to keep the pieces.
see bug #606736 for a new ebuild
please test again with fixed scons-3.0.1-r100
(In reply to Pacho Ramos from comment #10) > please test again with fixed scons-3.0.1-r100 Fails the same way with scons-3.0.1-r100. Or do you mean there was a fix to the scons ebuild without a revision bump and I need to reemerge scons?
To answer my own question: nothing changed after reemerging dev-util/scons-3.0.1-r100. And this has nothing to do with scons-3 and/or python-3, it fails the same way with dev-util/scons-2.5.1 as well. BTW, I am not allowed to reopen this bug, so if somebody who can gets a notification about this please do so.
