Sandbox-1.2.18.1-r1 fails to compile and exits with an error saying "configure: error: C compiler cannot create executables". I have no multilib system, and don´t have use-flag multilib set. Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. FEATURES=-sandbox emerge sandbox Actual Results: * Messages for package sys-apps/sandbox-1.2.18.1-r1: * If configure fails with a 'cannot run C compiled programs' error, try this: * FEATURES=-sandbox emerge sandbox * * ERROR: sys-apps/sandbox-1.2.18.1-r1 failed. * Call stack: * ebuild.sh, line 1695: Called dyn_compile * ebuild.sh, line 1033: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * sandbox-1.2.18.1-r1.ebuild, line 86: Called econf '--libdir=/usr/lib32' '--enable-multilib' * ebuild.sh, line 632: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed Expected Results: Sandbox compiles without --enable-multilib Portage 2.1.3.15 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.6.1-r0, 2.6.23-gentoo x86_64) ================================================================= System uname: 2.6.23-gentoo x86_64 Dual Core AMD Opteron(tm) Processor 185 Timestamp of tree: Sat, 20 Oct 2007 08:00:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.2-r1 dev-lang/python: 2.3.6-r2, 2.4.4-r4, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ " LINGUAS="en en_GB sv" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip X a52 aac acl acpi addbookmarks alias alsa amarok amd64 amd64codecs amr apm artworkextra asf audiofile automount bash-completion berkdb bitmap-fonts bl bluetooth browserplugin bzip2 cdda cddb cdparanoia cdr cdrecord cli connectionstatus contactnotes cpudetection cracklib crypt css cups daap dbus dmi dri dts dv dvd dvdnav dvdr dvdread emovix enca encode exif exscalibar fam fame ffmpeg fftw firefox flac fltk foomaticdb fortran fping fpx freedoom freetype gdbm gif glibc-compat20 glibc-omitfp glitz gnutils gphoto2 gpm graphviz gs gstreamer gtk hal hdri highlight iconv icq imagemagick ipv6 irc isdnlog jabber jbig jingle jpeg jpeg2k kde lame lash lcms libsamplerate libvisual linuxthreads-tls live lm_sensors logitech-mouse logrotate lua lzo mad matroska mbrola midi mikmod mjpeg mmx mmxext mng modplug mono mozilla mozsvg mp2 mp3 mp4 mpeg mplayer mtp mudflap musepack musicbrainz ncurses njb nls nptl nptlonly nsplugin nvidia nvidia-glx offensive ogg openal openexr opengl openmp osc pam pcre pda pdf perl pmu png portaudio postscript pppd python q32 qt3 qt3support qt4 quicktime rar readline reflection rtsp samba sdl sensors session skins slang smp sms sndfile sox speex spell spl sqlite srt sse sse2 sse3 ssl ssse3 stream subtitles svg tcpd texteffects tga theora threads tiff timidity tk truetype truetype-fonts type1-fonts udev unicode upnp usb vcd visualization vorbis vorbis-psy winpopup wmf wxwindows x264 xcomposite xine xinerama xml xorg xosd xpm xscreensaver xv xvid xvmc yv12 zlib" ALSA_CARDS="emu10k1x emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB sv" USERLAND="GNU" VIDEO_CARDS="nvidia nv mesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
(In reply to comment #0) > error: C compiler cannot create executables". I have no multilib system, and > don´t have use-flag multilib set. No, you don't - default-linux/amd64/2007.0 As for the error, search bugzilla for the tons of duplicates.
Created attachment 133933 [details] Build log
(In reply to comment #0) > error: C compiler cannot create executables". I have no multilib system, > and don´t have use-flag multilib set. To be a bit more verbose.. The multilib use flag has been deprecated for years in favour of multilib profiles. Your profile is a multilib profile so you do have multilib enabled.
(In reply to comment #3) > (In reply to comment #0) > > error: C compiler cannot create executables". I have no multilib system, > > and don´t have use-flag multilib set. > > To be a bit more verbose.. The multilib use flag has been deprecated for years > in favour of multilib profiles. Your profile is a multilib profile so you do > have multilib enabled. > Okay. Thanks for the clarification. Regardless of multilib, I can´t compile sandbox. Can someone be kind and point to a bug related to this one? I can´t seem to find one.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #0) > > > error: C compiler cannot create executables". > > > > To be a bit more verbose.. [try a no-multilib profile] > > > > Okay. Thanks for the clarification. Regardless of multilib, I can´t compile > sandbox. Can someone be kind and point to a bug related to this one? I can´t > seem to find one. Try bug #133209. See the number of duplicates? Bug wranglers understandably get a big grumpy after seeing the same thing repeatedly. Anyway, pay particular attention to comments 25,35,39, especially 39. (IOW, watch the quotes on the grep, the double-quotes on the command in comment 25 don't work so well on some installations, getting /way/ too many hits, but the single quotes used in the command as given in comment 39 should work better.) As for no-multilib, I'm running the 2007.0/no-multilib profile here in part due to getting fed up with this and similar bugs (before the fix above was known). It works great. Just watch for USE flag changes when you switch. gcc and glibc especially should merge much faster after switching to no-multilib, as you won't be compiling the 32-bit code, only the 64-bit code. Hope that solves your problem. =8^) Duncan
Created attachment 135219 [details] emerge --info emerge --info (k@splurben.com)
Created attachment 135220 [details] sandbox config log sandbox config log (k@splurben.com)
Created attachment 135221 [details] verbose output from emerge verbose output from emerge (k@splurben.com)
I have tried all the solutions listed here and I still can't upgrade sandbox. I'm also a bit fussed that it is acceptable to say, "Just delete a bunch of files from /usr/bin/ (which should certainly break something else) and then leave less accomplished Gentoo users breathing." It seems to me that SANDBOX's configure should be able to operate on a multilib amd64 machine, or we should be told not to use amd64 because it's not supported by sandbox which is a necessary component of the 2007.0 profile. I'm no expert, but there are plenty of references in these logs to i686 architecture which must be related to this package's inability to emerge. Here's my emerge --info, emerge transcript and config.log: emerge --info attached (I've also tried setting CTARGET to "x86_64-pc-linux-gnu" with no joy.) ----- FEATURES="-sandbox" emerge -v sandbox (output attached) ----- config.log (output attached)
(In reply to comment #9) > I'm also a bit fussed that it is acceptable to say, "Just delete a bunch of > files from /usr/bin/ (which should certainly break something else) and then > leave less accomplished Gentoo users breathing." The problem there is that gcc-config-2.0, which never left ~arch and perhaps was never even ~arch but may have remained entirely masked (IDR), was always a project in development. It never reached release quality as the guy developing it ran out of time and eventually moved on to projects other than Gentoo. (IIRC he was a Gentoo dev while in College, then after College...) While the project did have some advantages over our current gcc-config, it was never ever release quality, and one of the problems it continued to have is that certain parts of it had to be handled manually. One of the things that evidently needed handled manually was removal of certain files when it was unmerged. People knew when they installed it that some things needed done manually, and deliberately installed it anyway (as I said, it had benefits). Thus, for those people, deleting the relevant files manually was all part of cleaning up after what was after all, always a very experimental package. Of course, the borked quoting in the grep as first suggested, such that it listed way more files than it should have with some grep versions, didn't help, but the problem remained the same, users (including myself, so I'm not blaming anyone) mergeded an experimental package, and ended up having to clean up after it when they unmerged it. If they weren't ready to handle that sort of cleanup, they shouldn't have been playing with experimental packages such as that in the first place. (FWIW, I know the risk of experimental and ~arch, and still take it, because that's part of what I /do/ on the computer, test new stuff. Computing is a hobby of mine, not a job, and the challenge of fixing stuff that breaks occasionally is all part of the fun. Others, well...) > It seems to me that SANDBOX's configure should be able to operate on a > multilib amd64 machine, or we should be told not to use amd64 because > it's not supported by sandbox which is a necessary component of the > 2007.0 profile. > I'm no expert, but there are plenty of references in these logs to i686 > architecture which must be related to this package's inability to emerge. You don't seem to understand quite how multilib works. Multilib means that the system can run both 32-bit x86 and 64-bit x86_64 apps. On Gentoo, that means gcc is setup to be able to compile both 32-bit and 64-bit, tho 64-bit is normally used, and that glibc is compiled for both bitnesses. In ordered to work correctly, sandbox must then also be setup to work in both 32-bit and 64-bit mode, so it too is compiled for both bitnesses. When the 32-bit x86 portion is compiled, it's compiled using gcc's and glibc's 686 profile, so that's what you are seeing. Since only those three packages, glibc, gcc, and sandbox (well, I think parts of binutils also, but...) are normally partially compiled as 32-bit, and everything but sandbox has its own special-case code for handling it, sandbox is the most frequently problem for 32-bit compiling. ... Will glibc recompile successfully? If so, your gcc is still creating 32-bit code, so it would appear to remain a sandbox-only problem and I'm not sure where to go (altho you could try quickpkg-ing it from a stage tarball as I suggest below for gcc, and go from there). If not, then the root problem is probably that the 32-bit side of gcc is broken, and it's not a sandbox specific issue. In that case, I'd suggest quickpkg-ing a gcc binpkg from a different amd64 multilib system if you have one and merging that on the broken system. If you don't have another working amd64 multilib system, unpack a suitable stage tarball, chroot into it, and quickpackage its gcc, then merge that on your broken system and gcc-config to it. If it's a gcc problem, that should fix it and allow you to recompile sandbox, and then your broken gcc. HTH. Duncan.
Thank you for your concise comment. Once I got sandbox emerged I saw that it was compiling both bitnesses and your comment makes even more sense. Cheers, Kirk (In reply to comment #10) > (In reply to comment #9) > > I'm also a bit fussed that it is acceptable to say, "Just delete a bunch of > > files from /usr/bin/ (which should certainly break something else) and then > > leave less accomplished Gentoo users breathing." > > The problem there is that gcc-config-2.0, which never left ~arch and perhaps > was never even ~arch but may have remained entirely masked (IDR), was always a > project in development. It never reached release quality as the guy developing > it ran out of time and eventually moved on to projects other than Gentoo. > (IIRC he was a Gentoo dev while in College, then after College...) While the > project did have some advantages over our current gcc-config, it was never ever > release quality, and one of the problems it continued to have is that certain > parts of it had to be handled manually. > > One of the things that evidently needed handled manually was removal of certain > files when it was unmerged. People knew when they installed it that some > things needed done manually, and deliberately installed it anyway (as I said, > it had benefits). Thus, for those people, deleting the relevant files manually > was all part of cleaning up after what was after all, always a very > experimental package. > > Of course, the borked quoting in the grep as first suggested, such that it > listed way more files than it should have with some grep versions, didn't help, > but the problem remained the same, users (including myself, so I'm not blaming > anyone) mergeded an experimental package, and ended up having to clean up after > it when they unmerged it. If they weren't ready to handle that sort of > cleanup, they shouldn't have been playing with experimental packages such as > that in the first place. (FWIW, I know the risk of experimental and ~arch, and > still take it, because that's part of what I /do/ on the computer, test new > stuff. Computing is a hobby of mine, not a job, and the challenge of fixing > stuff that breaks occasionally is all part of the fun. Others, well...) > > > It seems to me that SANDBOX's configure should be able to operate on a > > multilib amd64 machine, or we should be told not to use amd64 because > > it's not supported by sandbox which is a necessary component of the > > 2007.0 profile. > > > I'm no expert, but there are plenty of references in these logs to i686 > > architecture which must be related to this package's inability to emerge. > > You don't seem to understand quite how multilib works. Multilib means that the > system can run both 32-bit x86 and 64-bit x86_64 apps. On Gentoo, that means > gcc is setup to be able to compile both 32-bit and 64-bit, tho 64-bit is > normally used, and that glibc is compiled for both bitnesses. In ordered to > work correctly, sandbox must then also be setup to work in both 32-bit and > 64-bit mode, so it too is compiled for both bitnesses. When the 32-bit x86 > portion is compiled, it's compiled using gcc's and glibc's 686 profile, so > that's what you are seeing. > > Since only those three packages, glibc, gcc, and sandbox (well, I think parts > of binutils also, but...) are normally partially compiled as 32-bit, and > everything but sandbox has its own special-case code for handling it, sandbox > is the most frequently problem for 32-bit compiling. > > ... > > Will glibc recompile successfully? If so, your gcc is still creating 32-bit > code, so it would appear to remain a sandbox-only problem and I'm not sure > where to go (altho you could try quickpkg-ing it from a stage tarball as I > suggest below for gcc, and go from there). If not, then the root problem is > probably that the 32-bit side of gcc is broken, and it's not a sandbox specific > issue. In that case, I'd suggest quickpkg-ing a gcc binpkg from a different > amd64 multilib system if you have one and merging that on the broken system. > If you don't have another working amd64 multilib system, unpack a suitable > stage tarball, chroot into it, and quickpackage its gcc, then merge that on > your broken system and gcc-config to it. If it's a gcc problem, that should > fix it and allow you to recompile sandbox, and then your broken gcc. > > HTH. Duncan. >
