emerge -pqv =gtk-vnc-0.4.1 [ebuild U ] net-libs/gtk-vnc-0.4.1 [0.3.10] USE="python -examples -sasl"
Created attachment 238723 [details] build.log
Created attachment 238725 [details] emerge --info =net-libs/gtk-vnc-0.4.1
More or less the same error here. Works with MAKEOPTS="-j1", though, so it is the parallel build which fails.
I didn't experience this parallel install problem with MAKEOPTS="-j2" :-/
Actually I just removed all tmp portage data (rm -rf /var/tmp/portage/*) and relaunched emerge, package installed without problem (using MAKEOPTS=-j5)
Installed for me with MAKEOPTS="-j1" (was MAKEOPTS="-j2"). "rm -rf /var/tmp/portage/*" don't resolved problem.
This is a issue with libtool, of the same kind as bug #253862. This will also probably not hit people who has not set USE="python" as it seems from the build.log
/var/tmp/portage/net-libs/gtk-vnc-0.4.1/work/gtk-vnc-0.4.1/src/.libs/libgtk-vnc-1.0.so: file not recognized: File truncated collect2: ld returned 1 exit status libtool: install: error: relink `gtkvnc.la' with the above command before installing it (quoted for quick reference, e.g. when checking for dupes)
Confirming, I can reliably reproduce on my laptop. Ping me in a couple of days if I haven't looked into it :) Cheers
Rémi, when you try to solve this problem, Could you please try to investigate a bit if libtool does really support parallel installations? Lennart Poettering told me that it wasn't supported: https://bugs.freedesktop.org/show_bug.cgi?id=28108#c1 I later was searching about it but never got any clear information :-(, after that, I mailed to gentoo-dev and SpanKY told me that parallel installations are supported but... well, seems that there are some bugs related with parallel installations :-/ Thanks :-)
I encountered this issue aswell while emerging gnome on my dads computer. Checked on my laptop and it produced the same compile failure. Emerging with MAKEOPTS="-j1" worked.
(In reply to comment #10) > Rémi, when you try to solve this problem, Could you please try to investigate > a bit if libtool does really support parallel installations? Lennart Poettering > told me that it wasn't supported: > https://bugs.freedesktop.org/show_bug.cgi?id=28108#c1 > > I later was searching about it but never got any clear information :-(, after > that, I mailed to gentoo-dev and SpanKY told me that parallel installations are > supported but... well, seems that there are some bugs related with parallel > installations :-/ Hey Pacho, I looked into it and here's a few things I found. Basically, there are 2 libs in src/ and there's no inherent reason for libtool to fail. However, both libs need to be relinked by libtool at 'make install' time (which we should fix), and *that's* what's failing, since you can't relink libgtk-vnc if libgvnc isn't relinked first. Bottom line, fixing this will probably require getting in touch with libtool folks to see what's wrong. Thanks
(In reply to comment #12) > Bottom line, fixing this will probably require getting in touch with libtool > folks to see what's wrong. Perhaps, in the meantime, the ebuild could force -j1? Ciao, Sheldon.
Same here with MAKEOPTS="-j5". Please add an explicit emake -j1 to the ebuild.
Will work it around; please keep this open until it's properly fixed though.
(In reply to comment #15) > Will work it around; please keep this open until it's properly fixed though. Diego, I've looked into this and I can't find an easy solution. You probably know more autotools than me and we'd definitely appreciate if you could look into it (time permitting, of course). Thanks
(In reply to comment #16) > (In reply to comment #15) > > Will work it around; please keep this open until it's properly fixed though. > > Diego, I've looked into this and I can't find an easy solution. You probably > know more autotools than me and we'd definitely appreciate if you could look > into it (time permitting, of course). > > Thanks > Do you want me to report this to gtk-vnc upstream? Maybe they will know better what to do... :-/
Hmm it could be worth a try to add --enable-fast-install that should target a build-for-install (rather than a build-for-run-in-builddir) which wouldn't have the race on install.
(In reply to comment #17) > Do you want me to report this to gtk-vnc upstream? Maybe they will know better > what to do... :-/ I doubt they'll know anything, this is purely a libtool/automake issue. Only those guys will know. Though we should definitely try what Diego suggested in comment #18. Cheers
(In reply to comment #18) > Hmm it could be worth a try to add --enable-fast-install that should target a > build-for-install (rather than a build-for-run-in-builddir) which wouldn't have > the race on install. > As read in configure help: --enable-fast-install[=PKGS] optimize for fast installation [default=yes] It's the default, or maybe you were referring to use "--disable-fast-install" instead (like suggested by others in bug #253862) ?
could someone with ccache disabled could check this again and provide a full build.log ?
(In reply to comment #21) > could someone with ccache disabled could check this again and provide a full > build.log ? > ping
Someone please get back to us.
(In reply to comment #21) > could someone with ccache disabled could check this again and provide a full > build.log ? > So you want someone to undo the addition of "-j1" that works around this problem with libtool and post a log of a build without ccache?
Created attachment 260975 [details] log of failing gtk-vnc I removed "-j1" from install phase and ran: id=1 ; while MAKEOPTS="-j" emerge -1q gtk-vnc ; do echo $((id++); done ; echo $id This happened on the 16 build. So I guess you can call this issue hard to reproduce... Portage 2.2.0_alpha19 (hardened/linux/amd64, gcc-4.5.2, glibc-2.12.2-r0, 2.6.36-hardened-r9 x86_64) ================================================================= System uname: Linux-2.6.36-hardened-r9-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 28 Jan 2011 09:00:23 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.4 [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1, 3.1.3 dev-util/ccache: 3.1.4 dev-util/cmake: 2.8.3-r1 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.7.0 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) Repositories: gentoo gamerlay-stable x11 mozilla Mine ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" DISTDIR="/var/portage/distfiles" FEATURES="assume-digests binpkg-logs buildpkg distlocks fixlafiles fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="ftp://ftp.sunet.se/pub/os/Linux/distributions/gentoo" INSTALL_MASK="*.la" LANG="sv_SE.UTF-8" LC_ALL="C" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--sort-common -Wl,--warn-once,--hash-style=gnu" LINGUAS="sv en" MAKEOPTS="-j16 -l15" PKGDIR="/var/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/var/overlays/layman/gamerlay /var/overlays/layman/x11 /var/overlays/layman/mozilla /var/overlays/mine" SYNC="rsync://liten.csbnet.se/gentoo-portage" USE="X a52 aac accessibility acl acpi alsa amd64 amr amrnb amrwb applet archive asyncns autoipd avahi bash-completion bluetooth branding bzip2 cairo caps ccache cdaudio cdda cdr cleartype cli clutter connection-sharing consolekit coverart cracklib crypt cups cxx dbus device-mapper devicekit devkit dhcpcd digitalradio djvu dri dts dvd dvdr dvi eds enca encode eselect evo exif faac faad fat fbcondecor ffmpeg fftw flac fluidsynth fontconfig fuse gdbm gdm gdu gif gimp glib gmp gnome gnome-keyring gphoto2 gpm grammar graphite gsf gsm gstreamer gtk gudev hardened hpn ical iconv iconvacl icq icu id3tag idn ieee1394 iptc ipv6 jabber jack java6 jingle jpeg jpeg2k justify kate kvm lcms libffi libnotify libsamplerate logrotate lvm lzma mad maps math matroska md mdadm midi mms mmx mmxext mng moonlight mp2 mp3 mpeg mpi msn mtp mudflap multilib musepack musicbrainz natspec nautilus ncurses network-cron networkmanager nfs nls nntp nptl nptlonly ntfs ntp nut offensive ogg openal opencore-amr opengl openmp openntpd ots pam pango parted pcre pdf perl pic pidgin playlist png policykit pppd pulseaudio python qt3support quicktime raw readline rrdcgi rtmp samba schroedinger seed sensord session smp sms speex spell sse sse2 sse3 ssl ssse3 startup-notification subversion svg sysfs test tex theora thesaurus threads tiff totem truetype udev unicode upnp urandom usb userlocales v4l2 vaapi vhook videos vim-syntax vorbis webkit wmf x264 xattr xcb xcomposite xml xmp xmpp xorg xrandr xscreensaver xulrunner xv xvid xvmc zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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" 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 ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv en" PHP_TARGETS="php5-3" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau" 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, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Maybe you could try passing --disable-fast-install at configure time :-/
Created attachment 260997 [details] as requested
I think that, if this can be reproduced when manually compiling, probably a bug to upstream should be opened
Could someone please open a tracker bug for packages in portage that fails because of the race condition in libtools relinking logic, at least this bug and bug #253862 should be depending on it. Time to get libtools fixed?
(In reply to comment #19) > (In reply to comment #17) > > Do you want me to report this to gtk-vnc upstream? Maybe they will know better > > what to do... :-/ > > I doubt they'll know anything, this is purely a libtool/automake issue. Only > those guys will know. > > Though we should definitely try what Diego suggested in comment #18. > > Cheers > CCing base-system people as hopefully they will know better about how to handle this problem (since these parallel *installation* problems look to affect to other like libcanberra, whose upstream thinks we shouldn't ever try to install in parallel :-/)
i dont see how this is a bug in libtool or automake. inter-library dependencies which exist in different dirs and their make targets are handled by the end package, not by libtool or automake. if foo/libfoo.la needs bar/libbar.la, then the end package needs to make sure that the bar subdir is always processed before the foo subdir. automake/libtool does not handle this for you in any way.
(In reply to comment #31) > if foo/libfoo.la needs bar/libbar.la, then the end package needs to make sure > that the bar subdir is always processed before the foo subdir. > automake/libtool does not handle this for you in any way. > The problem here is libtools relinking during "make install". In short all files exists, are where they should be, but if one or more files (often in the same subdir) are linked against another file in the same installation tree, then libtool think it needs to relink these files. The problem is if libtool is currently relinking the first file, while trying to relink the others. My question is if libtool really should try to relink against a file if it is currently relinking? The related race condition created normally would be fixed with some kind of locking.
my previous example still applies. if foo/libfoo.la needs bar/libbar.la, then the end package needs to make sure that the bar subdir is always processed (installed) before the foo subdir. what exactly is the .la layout of gtk-vnc in the build dir and how are they dependent upon each other ?
(In reply to comment #33) > what exactly is the .la layout of gtk-vnc in the build dir and how are they > dependent upon each other ? > Well, IIRC libgvnc i a dependency for libgtk-vnc, they resides inside the same subdir and the dependency is in the Makefile.am defined with gtk_vnc_LIBADD = libgvnc-1.0.la But libtool seems to parallellize the installation of lt_libraries in the same directory no matter the dependencies.
Maybe this is also caused by: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328 https://bugzilla.gnome.org/show_bug.cgi?id=644896
+*gtk-vnc-0.5.1 (21 Jul 2012) + + 21 Jul 2012; Pacho Ramos <pacho@gentoo.org> +gtk-vnc-0.5.1.ebuild, + -gtk-vnc-0.4.4.ebuild: + Version bump, drop old. Allow parallel installation again as upstream think it + should be fixed and looks to work ok for me. +
(In reply to comment #36) > +*gtk-vnc-0.5.1 (21 Jul 2012) > + > + 21 Jul 2012; Pacho Ramos <pacho@gentoo.org> +gtk-vnc-0.5.1.ebuild, > + -gtk-vnc-0.4.4.ebuild: > + Version bump, drop old. Allow parallel installation again as upstream > think it > + should be fixed and looks to work ok for me. > + Not fixed in 0.5.1. It fails for me, will attach build log.
Created attachment 325442 [details] build.log.gz
(In reply to comment #38) > Created attachment 325442 [details] > build.log.gz Please don't compress it two times, I need to rename it again after first uncompression to get it accepted by gunzip second time.
+ 01 Oct 2012; Pacho Ramos <pacho@gentoo.org> gtk-vnc-0.5.1.ebuild: + Parallel installation is still failing (#328273#c37 by Paweł Hajdan, Jr.). +
It's not compressed two times, it's a very old bug in bugzilla, and the reason why I'm using linked logs instead of attached/compressed logs.
I was referring to comment #38 and updated build.log
I know, that's what I was referring to as well. If you attach a gzip-compressed log, bugzilla will serve you up a twice-compressed file.
(In reply to comment #43) > I know, that's what I was referring to as well. If you attach a > gzip-compressed log, bugzilla will serve you up a twice-compressed file. Didn't know it was bugzilla what was causing me to need to run gunzip two times :S Thanks :)
i've re-released make-3.82-r4 with other sets of fixes from upstream
0.5.3 builds fine for me in parallel, the same for upstream please retest with that version
