There seems to be a header issue when compiling. I have dev-java/antlr-2.7.7-r5 installed, dev-java/antlr:3 seems to resolve the issue. Please update ebuild dependency. Build logs and emerge info attached. Reproducible: Always
Created attachment 375098 [details] build.log Portage 2.2.10 (default/linux/amd64/13.0/desktop/kde, gcc-4.8.2, glibc-2.17, 3.14.1-gentoo x86_64) ================================================================= System uname: Linux-3.14.1-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5-1650_0_@_3.20GHz-with-gentoo-2.2 KiB Mem: 16435000 total, 6119916 free KiB Swap: 4194300 total, 4194156 free Timestamp of tree: Wed, 16 Apr 2014 16:15:01 +0000 ld GNU ld (GNU Binutils) 2.24 app-shells/bash: 4.2_p47 dev-java/java-config: 2.2.0::java dev-lang/python: 2.7.6, 3.3.5, 3.4.0 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28-r1 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.14.1 sys-devel/binutils: 2.24-r2 sys-devel/gcc: 4.8.2 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.14 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo java wtk luman local_overlay ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="${CONFIG_PROTECT} /etc /etc/idea/conf /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.1/conf /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /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/terminfo" CXXFLAGS="-march=native -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" 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" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j14" 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="/var/lib/layman/java /var/lib/layman/wtk /var/lib/layman/luman /usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 avx berkdb branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups custom-cflags cxx dbus declarative dri dts dvd dvdr embedded emboss encode exif fam ffmpeg firefox flac fortran gd gdbm gif git gpm gtk iconv icu ipv6 java jpeg kde kipi lcms ldap libnotify lm_sensors lzma lzo mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls nptl offensive ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds qt3support qt4 rar readline sdl session spell sqlite sse sse2 sse4 sse4_1 sse4_2 ssl ssse3 startup-notification svg svn tcpd threads tiff truetype udev udisks unicode upower usb vdpau vorbis wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zip zlib" 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="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 en_US" NETBEANS_MODULES="apisupport cnd dlight enterprise ergonomics harness ide java mobility nb php profiler platform webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" 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, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Please scratch the dev-java/antlr:3 resolution, that does not make a difference.
Installing dev-libs/antlr-c should help, but that version is broken and mysql-workbench should use a bundled version instead.
I can't reproduce this even with antlr-c uninstalled, but I suspect it might be a parallel build issue. Could you try again with MAKEOPTS=-j1 ?
(In reply to Hans de Graaff from comment #4) > I can't reproduce this even with antlr-c uninstalled, but I suspect it might > be a parallel build issue. Could you try again with MAKEOPTS=-j1 ? Definitely a parallel issue. Seems to work fine at MAKEOPTS=-j1.
I have a rather nasty work around idea which would greatly slow down builds. Is it possible to have the ebuild file ignore the make -j options in make.conf and use one set by the e build which drops it down to -j1 if that fixes the issue for now. I am discussing this with an upstream dev as i was told what happens is that antlr would still be compiling and another part running in parallel needs antlr which has not been completely compiled.
(In reply to Jonathan Aquilina from comment #6) > Is it possible to have the ebuild file ignore the make -j options in > make.conf and use one set by the e build which drops it down to -j1 if that > fixes the issue for now. I've now done that for mysql-workbench-6.1.4 > I am discussing this with an upstream dev as i was told what happens is that > antlr would still be compiling and another part running in parallel needs > antlr which has not been completely compiled. Yes, that is also my understanding from seeing the log file. Is there an upstream bug for it? If so please add the URL so we can keep track of the issue.
Sadly no upstream bug, but i did speak to a dev who said he will try and look into it, as they dont see gentoo as a supported system for some reason.
I think for me there was no need to drop to -j1 i was using -j16 which is double the amount of cores my cpu has. dropping down to -j8 and doing a recompile of workbench seems to work and completes successfully.
(In reply to Jonathan Aquilina from comment #8) > Sadly no upstream bug, but i did speak to a dev who said he will try and > look into it, as they dont see gentoo as a supported system for some reason. This problem would affect anyone building from source, not just Gentoo users. (In reply to Jonathan Aquilina from comment #9) > I think for me there was no need to drop to -j1 i was using -j16 which is > double the amount of cores my cpu has. dropping down to -j8 and doing a > recompile of workbench seems to work and completes successfully. We can only reliably fix this with -j1 since that will avoid the bugs in the build system altogether. -j8 might work for you but not for someone else who has faster/slower hardware and varying load on their machine while building. -j1 is the only reliable option in this case, sadly.
*** Bug 515994 has been marked as a duplicate of this bug. ***
*** Bug 516672 has been marked as a duplicate of this bug. ***
I see that version 6.2.3 still suffers from the parallel make build issue...
(In reply to Vasilis Lourdas from comment #13) > I see that version 6.2.3 still suffers from the parallel make build issue... Yes, and this will be true as long as the included antlr code is used. The only solutions I see are to get an antlr 3.6 release that includes all the fixes that mysql-workbench needs, or someone more knowledgable than me about cmake may be able to track down the parallel build bug and provide a patch.
I have tried building the latest version 6.3.3 commenting out the src_compile() function (which forces -j1). It seems that the parallel build mode works again cutting the process time to about 33% on my system: $ qlop -tvgH mysql-workbench mysql-workbench-6.2.5: Sat Mar 7 19:20:07 2015: 1 hour, 13 minutes, 34 seconds mysql-workbench-6.3.3: Sat May 2 13:57:39 2015: 24 minutes, 19 seconds I have successfully tried twice, it would be good if this is reproducible on other systems so that the-j1 workaround can be removed to speed up the compilation process.
I confirm the same behavior by removing -j1 from the ebuild. Version 6.3.3 compiles and runs just fine and the build time drops significantly. Sun Apr 5 20:33:56 2015 >>> dev-db/mysql-workbench-6.2.5 merge time: 35 minutes and 25 seconds. Sun May 3 15:20:57 2015 >>> dev-db/mysql-workbench-6.3.3 merge time: 11 minutes and 14 seconds.
any news here? today I have upgraded to version 6.3.4 but the -j1 workaround is still there
(In reply to Fabio Rossi from comment #17) > any news here? today I have upgraded to version 6.3.4 but the -j1 workaround > is still there I keep reporting bugs upstream and I keep getting the same response, you are on an unsupported platform using unsupported dependencies. Even though the response has nothing to do with the problem being reported, they refuse to look into them further. I have pretty much given up on this package because its been years and years of the same crap... new versions, new bugs, and no fixes. I recommend using www.heidisql.com with wine for stability.
(In reply to Alex Barker from comment #18) > I keep reporting bugs upstream and I keep getting the same response, you are > on an unsupported platform using unsupported dependencies. Even though the > response has nothing to do with the problem being reported, they refuse to > look into them further. I have pretty much given up on this package because > its been years and years of the same crap... new versions, new bugs, and no > fixes. I recommend using www.heidisql.com with wine for stability. +1000 That's why many accused Oracle of their behavior against community and their open sources projects. That's why many big Linux distros turned to MariaDB as their default database. The only decent feature that Workbench has is the modeling tool. Other than that, it's slow and buggy. As long new features are supposed to be introduced with each new major version, new bugs also appear. HeidiSQL is an excellent alternatives for all other jobs besides modeling. It's extremely fast too and runs pretty well with wine.
(In reply to Alex Barker from comment #18) > (In reply to Fabio Rossi from comment #17) > > any news here? today I have upgraded to version 6.3.4 but the -j1 workaround > > is still there > > I keep reporting bugs upstream and I keep getting the same response, you are > on an unsupported platform using unsupported dependencies. Even though the > response has nothing to do with the problem being reported, they refuse to > look into them further. I have pretty much given up on this package because > its been years and years of the same crap... new versions, new bugs, and no > fixes. I recommend using www.heidisql.com with wine for stability. There is a misunderstanding, there are no more problems upstream and for this reason there is no need of -j1 hack in the ebuild, the ebuild should be updated removing the -j1 stuff. I have compiled successfully version 6.3.3 and 6.3.4 without -j1
(In reply to Fabio Rossi from comment #20) > There is a misunderstanding, there are no more problems upstream and for > this reason there is no need of -j1 hack in the ebuild, the ebuild should be > updated removing the -j1 stuff. I have compiled successfully version 6.3.3 > and 6.3.4 without -j1 Can you point me to the specific fixes that upstream applied? If you are just basing this on your own observations than unfortunately with race conditions like these absence of proof isn't proof of absence.
(In reply to Hans de Graaff from comment #21) > Can you point me to the specific fixes that upstream applied? If you are > just basing this on your own observations than unfortunately with race > conditions like these absence of proof isn't proof of absence. As upstream devs didn't recognize the problem, I don't think you can find a specific reference in the upstream repository. It's likely that a change in the build system has solved the issue but unfortunately I cannot indicate what. I understand your position but upstream is not interested in the problem (if still exists) while downstream is not interested in looking at the build system so I can't see a real solution of the problem (the -j1 hack is a conservative workaround but increases very much the building time in this case - more than 1 hour on my old first generation i7 CPU).
My #16 comment states that removing -j1 from the compile phase works fine and I still confirm the case with 6.3.4-r2. Maybe it's time to drop this hack and reduce the compiling time for mysql-workbench?
I have now put antlr-c 3.5.2 in the tree, which includes the necessary fixes. Unbundling it from mysql-workbench would be nice, regardless of the parallel build issue.
More than a year afterwards and still this bug is open. I've modified the newly committed 6.3.9 version and removed the -j1 switch and the application compiled just fine. When will this switch be finally dropped?
Maybe it's time to remove the -j1 workaround in the ebuild?
mysql-workbench 8.0.13 depends on antlr-cpp instead of an in-tree version of antlr so the -j1 workaround has been dropped for this version
