Summary: | xlockmore doesn't install /usr/bin/xlock | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Reffett (RETIRED) <creffett> |
Component: | Current packages | Assignee: | Desktop Misc. Team <desktop-misc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ComputerDruid, flameeyes |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | xlockmore build.log |
Description
Chris Reffett (RETIRED)
2009-09-17 01:52:42 UTC
I cannot reproduce the problem. Can you please post the output of emerge -pv xlockmore 2011creffett@meson ~ $ emerge -pv xlockmore These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-misc/xlockmore-5.28 USE="crypt esd gtk motif opengl pam truetype -debug -nas -xlockrc" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Works for me. Need a full build.log. Created attachment 204609 [details]
xlockmore build.log
Here's the build.log. Note the line at the end that says "chmod: cannot access `/var/tmp/portage/x11-misc/xlockmore-5.28/image//usr/bin/xlock': No such file or directory"
Build deps problem: "/usr/X11R6/include/freetype/freetype.h", line 27: Error: #error "This is freetype.h of FreeType 1!". Why was this assigned to x11? Cheers Ah: note the following error: "/usr/X11R6/include/freetype/freetype.h", line 27: Error: #error "This is freetype.h of FreeType 1!". which occurs twice, once during the build and once when it is trying to install. Why this didn't cause the ebuild to fail, though, I'm not sure... Seems to be a freetype-related error. The box in question has both slots of freetype installed. Would it be worth trying to remove the dependencies on freetype:1 and unmerging it, and then remerging xlockmore? The freetype error doesn't seem to be the problem, as this bug still shows up with USE="-truetype". In fact, ld seems to be failing out: "/opt/SunStudioExpress/prod/lib/amd64/ld: unrecognised emulation mode: no-tls-direct-seg-refs" It's using sun studio express. Even though as far as I know, the machine is not configured to do so unless called explicitly. this seems to be called from the "CC -O2 -march=core2 -mno-tls-direct-seg-refs -pipe -o ../xlock/xlock ../xlock/xlock.o ..." line (rather long) apparently because the configure script found CC before another c++ compiler: "checking for CC... CC checking whether we are using the GNU C++ compiler... no" CC being sun studio express: "equery b CC [ Searching for file(s) CC in *... ] dev-lang/sunstudioexpress-2009.03 (/opt/SunStudioExpress/prod/include/CC) dev-lang/sunstudioexpress-2009.03 (/opt/SunStudioExpress/bin/CC -> ../prod/bin/CC) dev-lang/sunstudioexpress-2009.03 (/opt/SunStudioExpress/prod/bin/CC)" which, isn't right, of course. We want to be using gcc (g++). Especially since we're using gcc-specific flags. Does anyone know why the configure script would have found this one before gcc's? Does it help if you add 'toolchain-funcs' to inherit line of the ebuild, and 'tc-export CC' to the beginning of src_configure() function? Diego, seriously, is sunstudioexpress adding CC binary to default search path? Uhm it might… but there are a few notes there: - nothing sane should use CC as default name, rather cc…; - we have a $CC variable just to avoid stuff like that; - sunstudioexpress is masked, feel free to punt. AC_PROG_CC dnl Check if C++ compiler is present. If not set CXX to the C-compiler used OK, sunstudioexpress is punted now. sigh: dnl for the other compilations. if test "$CC" = gcc; then AC_CHECK_PROGS(CXX, $CCC g++ CC C++ c++ cxx cc++ xlC $CC, gcc) else AC_CHECK_PROGS(CXX, $CCC CC C++ g++ c++ cxx cc++ xlC $CC, gcc) fi AC_PROG_CXX if test "${CXX}" = "xlC" ; then CXXFLAGS="${CXXFLAGS} -+" fi 14 Feb 2010; Samuli Suominen <ssuominen@gentoo.org> + xlockmore-5.29.1.ebuild, +files/xlockmore-5.29.1-configure.in.patch: + Remove extra CC and CXX checks from configure.in to avoid #285262. |