Ignoring, for the moment, that gcc may well have good reasons for issuing these warnings: building mysql-workbench with gcc7 currently seems to require: -Wno-error=implicit-fallthrough and -Wno-error=strict-aliasing cflags. Observed Nov 2 2017 on my reasonably configured ~amd64 workstation, against standard =dev-lang/gcc-7.2.0::gentoo. Detailed blah is available if anybody cares (not complaining, just, you know, being realistic :P). My $(emerge --pretend dev-db/mysql{,-workbench}) looks sort-of like: dev-db/mysql-workbench-6.3.9::gentoo USE="gnome-keyring -debug -doc"\ PYTHON_TARGETS="python2_7" dev-db/mysql-5.6.38:0/18::gentoo USE="embedded openssl perl server "\ "-debug -extraengine -jemalloc -latin1 -libressl -profiling (-selinux)"\ "-static -static-libs -systemtap -tcmalloc {-test} -yassl" \ ABI_X86="32 (64) (-x32)" However, I instinctively doubt it's oracle-specific, so much as probably red-headed-stepchild-related, i.e., quite plausible nobody tried yet or nobody bothered to report/diagnose. Then, it needs this lovely nugget (maintainers should feel free to upgrade this to however such things are properly handled in C++ nowadays, and meticulously upstream it. Disclaimer: I know, a hideous (maybe even wrong?) solution. But, it's mysql-workbench -- just pretend it's ransomware, basically; all 100 zillion lines of code look exactly like the below ... it's NSFW application software basically. --- a/backend/wbprivate/workbench/wb_model_file.cpp 2017-02-03 10:40:18.000000000 -0800 +++ b/backend/wbprivate/workbench/wb_model_file.cpp 2017-11-02 03:22:56.923575633 -0700 @@ -145,10 +145,12 @@ static int rmdir_recursively(const char std::string ModelFile::create_document_dir(const std::string &dir, const std::string &prefix) { std::string path; - char s[10]; + char s[12]; int i = 0; - strcpy(s, "d"); + //strcpy(s, "d"); + s[0]='d'; + s[1]='\0'; for (;;) { path = dir + "/" + prefix + s;
I can't really tell if you are presenting a solution (patch) or not here. Therefore, please provide emerge --info and attach a build log.
No, not a complete solution. The patch solves a legitimate (I assume) problem in the code that gcc7 no longer lets one get away with. The -Wno-error things are separate issues for which I have not properly solved, but presume a solution would be fairly self-evident (i.e.: use flag-o-matic). The two build failures (the patch one and the "-Wno-error" ones) are orthogonal but for the fact that using gcc7 builds fail on both. That stated, I could have just finished the job and produced a nice PR solving both, so I'll give that a shot and follow up here once I have something more "edible"
OK, see PR #6125. PR was worth 339 words according to wc :)
Can confirm that the ebuild from PR #6125 builds without error and that mysql-workbench works flawlessly.
I can definitely understand Gentoo not wanting to have 10^7 ancient and irrelevant PR's gumming up the works in github projects, so, no big deal that my PR got nixed. aside: I would like to express my appreciation for Gentoo's toleration of lingering, valid 'zilla bugs that no maintainer gives a shit about, rather than habitually dusting them under the carpet in pursuit of I-know-not-what like some other projects*. In Gentoo I find lingering bugs like this very often contain workarounds or even fully fleshed out solutions to rather impactful problems and are a helpful resource for end-users, (or at least for me). For the record, I have had /etc/portage/package.env equivalents to my PR, happily doing their thing without incident, for the entire year or however long it's been. Not perfect to hear they are still doing something useful (would rather upstream had fixed the problem in the meanwhile) but ... well, not every bug is equally important, and there's only so much time in a day... * My inner paranoid always suspects this practice is championed by someone who plans to brag about bug-closing metrics as a sign of project health at some conference :)
I stand corrected: I had to add "-Wno-error=deprecated-declarations" to "append-flags" in the ebuild to compile without error.
dev-db/mysql-workbench-8.0.13 compiles fine for me with gcc7. I don't expect to backport any fixes to 6.x versions at this time.
(In reply to Hans de Graaff from comment #7) > dev-db/mysql-workbench-8.0.13 compiles fine for me with gcc7. I don't expect > to backport any fixes to 6.x versions at this time. That explains everything then (I hadn't noticed the version bump). In that case the value proposition of keeping this bug open seems a lot less convincing :) I'll probably close if nobody objects.
(In reply to Greg Turner from comment #8) > (In reply to Hans de Graaff from comment #7) > > dev-db/mysql-workbench-8.0.13 compiles fine for me with gcc7. I don't expect > > to backport any fixes to 6.x versions at this time. > > That explains everything then (I hadn't noticed the version bump). In that > case the value proposition of keeping this bug open seems a lot less > convincing :) I'll probably close if nobody objects. That version only got added very recently. I'll close this bug but please feel free to re-open if there are still issues with gcc 7 and that version.
