Build hangs if using GCC with Graphite enabled. Disabling Graphite via package.env resolves the problem. Reproducible: Always Steps to Reproduce: 1. Build gcc with USE="graphite" 2. emerge =media-libs/libprojectm-2.1.0-r1 Actual Results: Build hangs. Expected Results: Build should succeed. Portage 2.2.8-r1 (default/linux/amd64/13.0, gcc-4.8.2, glibc-2.17, 3.10.17-gentoo-rocky_fglrx x86_64) ================================================================= System uname: Linux-3.10.17-gentoo-rocky_fglrx-x86_64-AMD_A8-3850_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.2 KiB Mem: 7839664 total, 2141640 free KiB Swap: 12582908 total, 12582908 free Timestamp of tree: Sat, 12 Apr 2014 00:45:01 +0000 ld GNU gold (GNU Binutils 2.23.2) 1.11 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.9 [disabled] app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6, 3.3.4 dev-util/ccache: 3.1.9-r3 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1, 4.8.2 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.10 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo rocky gamerlay ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA -CDDL -CDDL-Schily" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=amdfam10 -O3 -pipe -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /home/mythtv/ /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=amdfam10 -O3 -pipe -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-march=amdfam10 -O3 -pipe -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fuse-linker-plugin" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/overlay /var/lib/layman/gamerlay" USE="3dnow 3dnowext X aacs alsa amd64 berkdb bluray bzip2 cairo ccache cddb cjk cli cracklib crypt curl cxx dbus device-mapper djbfft dri dvb dvd faac faad flac fontconfig fortran gdbm gif graphite iconv ipv6 jack jbig jpeg jpeg2k lcms libnotify lto mmx mmxext modules mp3 multilib musicbrainz ncurses nls nptl ogg openal opengl openmp pam pcre perl png python readline rle session sndfile sse sse2 sse4_1 ssl startup-notification tcpd theora tiff truetype udev unicode v4l vim-syntax vorbis xft xv zlib zsh-completion" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="fuji directory ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB" LIRC_DEVICES="all" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" SANE_BACKENDS="epson epson2" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Created attachment 375160 [details] media-libs:libprojectm-2.1.0-r1:20140417-214348.log
In bug #507666 you haven't yet established that with enough RAM and enough CPU time, the build would finish.
Well, I already have 8GB of RAM and 12GB of swap. How much RAM should I reasonably be expected to have, and how many hours should I reasonably be expected to wait, just to build a tiny 157K binary that normally builds in seconds?
So setting obviously broken compiler flags is cause to file bug reports against the code that the compiler apparently doesn't handle very well? *** This bug has been marked as a duplicate of bug 507666 ***
If USE="graphite" is an "obviously broken compiler flag", then why was it provided in the first place? Do you intend to support that feature or not? Also, it doesn't seem especially "broken" for most of the other 1674 packages on my system, so it's far more likely that the thing that's actually broken is this package. Not that I'm desperate for a solution, given that I can circumvent it simply by changing the compiler flags in package.env, and I fully acknowledge that Graphite is an experimental feature, but the fact is you've provided that option, and for this package it doesn't work, so I'm dutifully reporting that fact, in case anyone is actually interested in fixing it. This is bugzilla, not a petition site. I'm filing a bug report, a fairly standard procedure in software development, not making a complaint, so to respond to that report as though I'm just complaining for the hell of it is irrational, and also rather unusual, given that you didn't seem especially bothered by any of the other bugs filed against Graphite. https://bugs.gentoo.org/buglist.cgi?quicksearch=Graphite But if this is more than you can bear that please feel free to remove USE="graphite" from Portage, as well as every other experimental feature and unstable package, and I'm sure your bug reports will drop dramatically, along with any actual improvement in software.
(In reply to Homer from comment #5) > If USE="graphite" is an "obviously broken compiler flag", then why was it > provided in the first place? Do you intend to support that feature or not? Providing USE="graphite" is a good way to unbreak the USE flag. > Also, it doesn't seem especially "broken" for most of the other 1674 > packages on my system, so it's far more likely that the thing that's > actually broken is this package. Just because your car managed not to drive into 1674 walls doesn't mean that the next wall you drive into makes that wall be the problem. https://www.youtube.com/watch?v=aLOjxmBLYT4 > Not that I'm desperate for a solution, given that I can circumvent it simply > by changing the compiler flags in package.env, and I fully acknowledge that > Graphite is an experimental feature, but the fact is you've provided that > option, and for this package it doesn't work, so I'm dutifully reporting > that fact, in case anyone is actually interested in fixing it. No problem with that. > This is bugzilla, not a petition site. I'm filing a bug report, a fairly > standard procedure in software development, not making a complaint, so to > respond to that report as though I'm just complaining for the hell of it is > irrational, and also rather unusual, given that you didn't seem especially > bothered by any of the other bugs filed against Graphite. > > https://bugs.gentoo.org/buglist.cgi?quicksearch=Graphite A bug report contains details about the bug; in this case, I see no details about a bug with the package. All we see is PID 11401 bail out. What is this PID? Why does it catch a signal? A signal from where? Why does that other process send a signal? Which part of code of that process sends this signal? The first problem here is MAKEOPTS="-j5"; by using that, we're not able to tell what actually failed. So, we can put this to MAKEOPTS="-j1" and the failure will be the line before (assuming there is no invisible output) the process that sends the signal. From here on, you can run that compiler command; when you do that, and it is in fact the problematic command, you can then go further to manipulate that command. You could try to run it to strace and ltrace to see what it is doing; or perhaps a step further, step through it with a debugger and/or set a few breakpoints to speed up the debugging process. You can also pass the -E option to the compiler command to obtain preprocessed files; there are other options, perhaps one of them makes things more verbose and leads to even more details. When you have these details, we can assign this bug to toolchain for inspection. > But if this is more than you can bear that please feel free to remove > USE="graphite" from Portage, as well as every other experimental feature and > unstable package, and I'm sure your bug reports will drop dramatically, > along with any actual improvement in software. That would be a regression.
(In reply to Tom Wijsman (TomWij) from comment #6) > Just because your car managed not to drive into 1674 walls doesn't mean that > the next wall you drive into makes that wall be the problem. What a silly analogy. Cars typically do not drive themselves into walls. When they do then clearly the problem is the car, not the wall. On this occasion you seem to be suggesting that 1674 walls are somehow dysfunctional because a car crashed into one of them, which doesn't make any sense. > A bug report contains details about the bug; in this case, I see no details > about a bug with the package. All we see is PID 11401 bail out. What is this > PID? Why does it catch a signal? A signal from where? Sorry, but I assumed the cause was obvious from the description. The signal came from me ctrl-c killing the process, which is typically what one does when a process hangs for hours and consumes all available memory. Without Graphite, that tiny package usually compiles in a few seconds, so obviously something is not right. What exactly that might be is a complete mystery to me without an actual error message to work with, and there wasn't one. > You could try to run it to strace and ltrace to see what it is > doing; or perhaps a step further, step through it with a debugger and/or set > a few breakpoints to speed up the debugging process. You can also pass the > -E option to the compiler command to obtain preprocessed files; there are > other options, perhaps one of them makes things more verbose and leads to > even more details. I'll compile the package manually (outside Portage) using the problematic compiler flags and see if I can diagnose the problem further. As the problem is clearly some kind of memory leak, I assume Valgrind in the best tool for the job, but this is already on the fringes of my very limited expertise, so it might be a while before I have anything to report.
(In reply to Homer from comment #7) > Cars typically do not drive themselves into walls. Exactly, thus the car (aka compiler) is dysfunctional; as the analogy suggests. > [...] process hangs for hours [...] Ah, you might be able to attach to it using gdb; to more easily get a backtrace. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
I got as far as extracting and patching the sources. However, I have no idea how to implement this from the ebuild, to recreate the same build conditions: if use video_cards_nvidia; then append-ldflags -L/opt/nvidia-cg-toolkit/$(get_libdir) append-ldflags -L/opt/nvidia-cg-toolkit/lib append-cppflags -I/opt/nvidia-cg-toolkit/include fi local mycmakeargs=( $(cmake-utils_use_use video_cards_nvidia CG) "-DUSE_OPENMP=OFF" "-DprojectM_FONT_MENU=${EPREFIX}/usr/share/fonts/dejavu/DejaVuSans.ttf" "-DprojectM_FONT_TITLE=${EPREFIX}/usr/share/fonts/dejavu/DejaVuSansMono.ttf" ) if use openmp && tc-has-openmp; then mycmakeargs+=( $(cmake-utils_use_use openmp) ) fi Also, when I run cmake I get this error: CMake Error at src/projectM-pulseaudio/FindPkgConfig.cmake:350 (message): None of the required 'libpulse>=0.9.8' found I don't use PulseAudio, and whatever mechanism Portage uses to pass that information to cmake is a total mystery to me, as is cmake and the entire C++ language in general.
