It was released a few days back (this bug report was initially for 5.2.41).
Can we do anything to help with this one? I've tried to simply rename ebuild in local overlay, but compilation failed and I was unable to find the cause of that. Anyway the .40 version keeps crashing, so I am looking forward to next versions...
Preferable we should use Gentoo's antlr-c runtime, see bug 428214. As a second option we could use the version bundled with mysql-workbench, at least temporarily, but that does not compile. I have not had time to look at this in detail, but at least this could be reported upstream (and perhaps it already has). Bonus points for patches that fix things :-) My Gentoo time is limited right now so I don't know when I'll get to this. Feel free to beat me to it.
(In reply to comment #1) > Anyway the .40 version keeps crashing, so I am looking forward to next > versions... No bug?
(In reply to comment #3) > (In reply to comment #1) > > > Anyway the .40 version keeps crashing, so I am looking forward to next > > versions... > > No bug? Well, it seems me to me that MySQL Workbench has had a lot of bugs lately, other minor, other major (like crashes). I wouldn't called it a (relatively) bug-free software. Version .42 had another crash issue, which I reported upstream (platform specific, Windows only) and it is fixed in the upcoming .43. Maybe we can wait for this version to bump in the tree.
(In reply to comment #3) > (In reply to comment #1) > > > Anyway the .40 version keeps crashing, so I am looking forward to next > > versions... > > No bug? Hard to track down, as those are random crashes when working on some databases (I have one on which it crashes every few queries, but couldn't ever provide test-case showing behavior). I'll try to narrow down the building problems again, but I'm not an expert so I may fail one more time.
antlr-c-3.4 seems easy to have. Although mysql-workbench seems to be mislead by it's own configure script in this matter: int main() { return strcmp(PACKAGE_VERSION, "3.4") >= 0; } as far as I understand returns non-zero value when 3.4 is found, making the case exactly opposite to expected. Unfortunately I didn't make it to fix the configure script into working one in that matter. Seems I lack expertise there :(
mysql-workbench-5.2.43 - exactly the same behavior.
Got it! Upon replacing ext/antlr-runtime/libtool with system one (simply remove and copy from /usr/bin/libtool) everything compiles, installs and runs fine. Looks like the problem is in bundled / created by configure libtool file (I have no idea how libtool works ;) ). Now there is a question how can we fix this in ebuild? Probably moving files between system and work directory after compile phase is not possible?
Created attachment 323988 [details, diff] Patch to force using system libtool Maybe a little dirty, but I have no expert knowledge in autoreconf etc. Changing this one path in ext/antlr-runtime/configure makes make use system libtool instead of broken bundled one. That makes workbench build.
Created attachment 323990 [details] My ebuild using attached patch It builds and I run it for a few days now in production situations and must say it's much more stable than 5.240 currently in tree. I hope to get this version in the tree so everyone can benefit from it.
(In reply to comment #8) > Looks like the problem is in bundled / created by configure libtool file (I > have no idea how libtool works ;) ). I think it is partly created by configure. Thanks for digging in here. I've fixed this instead by including an eautoreconf call in the ebuild to recreate all the autotools stuff into a consistent state. So, 5.2.43 now in CVS.
You are very welcome :) It's a pleasure to help.
