workbench-5.1.1-alpha on Fedora 9
So, you want to compile Workbench for Linux, on Fedora 9. You need to install the following packages:
autoconf automake libtool libzip-devel libxml2-devel libsigc++20-devel libglade2-devel gtkmm24-devel mesa-libGLU-devel mysql-libs mysql mysql-devel uuid-devel lua-devel glitz-devel glitz-glx-devel pixman-devel pcre-devel libgnome-devel gtk+-devel pango-devel cairo
I feel I’m being too liberal with dependencies, but I’m not about to strip it, I just want to get it working first :)
You need to have ctemplate and ctemplate-devel installed from updates-testing-newkey (relevant koji build log).
By default, configure.in in Workbench looks for “google-ctemplate”, as opposed to just “ctemplate” as Fedora calls it. You can fix this (easy), or “cheat” – in /usr/local/include you can do sudo ln -s /usr/include/ctemplate google. Take your pick.
Now for the fun. Fedora includes gcc-4.3. Ubuntu ships gcc-4.2. Let’s just say gcc-4.3 got stricter (its C++ header dependency streamlining related). So strict, they have a useful porting to gcc-4.3 guide. Just FYI, I believe OpenSUSE is also shipping a more modern GCC (I expect the next Ubuntu release in the coming month to do the same).
So, start getting used to doing the following in files that lead the compiler to fail:
- #include <cstring>
- #include <algorithm>
- #include <memory>
- #include <climits>
- #include <cstdlib>
This will help get rid of error messages like: error: 'memset' was not declared in this scope. This stuff is already fixed in trunk (or the patch is being applied).
You will need to pick up cairo from source. Why? Because --enable-glitz isn’t on by default in the RPM spec file (similar with Ubuntu). The glitz backend is apparently still a release preview and doesn’t fully work yet. (I have spoken to Alfredo, and he says he’s just removed the requirement on glitz in trunk).
Now, once you’ve built cairo with glitz, before running ./autogen.sh, do: export PKGCONFIG_PATH=/usr/local/lib/pkgconfig. Then go ahead and make it.
There are still plenty of warnings that spew by. I have this vague idea that once Workbench for Linux sits on Launchpad, we’ll run a janitorial tree that fixes warnings in the code. A great way to garner community contributions!
Anyway, a lot of this is either fixed or patches will be applied to trunk. I expect a mysql-workbench-5.1.2-alpha out sooner than you think to eclipse 5.1.1-alpha. Again, superb work Alfredo (and MikeZ and the rest of the GUI team).
Thanks to you for this Colin and to the WB team for all the refinement entailed by the rewrite and delivery of my ERD tool of choice.
I think that in view of the copy/paste scenario, a correction of
<>
to either
<>
or
<>
might well avoid a scratched head or two.
[Tried to use a ghetto macron with doubled less-than/greater-than characters and got parsed into ellipsis; sorry for the repost.]
Thanks to you for this Colin and to the WB team for all the refinement entailed by the rewrite and delivery of my ERD tool of choice.
I think that in view of the copy/paste scenario, a correction of
export PATH=/usr/local/lib/pkgconfig.
to either
export PATH=$PATH:/usr/local/lib/pkgconfig; $(echo $COMMAND_STRING)
or the limited scope
PATH=$PATH:/usr/local/lib/pkgconfig $(echo $COMMAND_STRING)
might well avoid a scratched head or two.
Hi David,
Regarding your first comment, I don’t know what you’re referring to <>. There is no copy paste scenario, you’re expected to use either one of the include files that are missing.
Now, with the second post, I made a tiny boo boo (make note to self: don’t write technical blog posts when in a semi-drunken and tired state)
You want to do:
export PKGCONFIG_PATH= instead of export PATH.
Sorry, I fixed the blog post
Sorry Colin,
My first post was ruined by my attempt to pseudo-quote a string with double less-than signs followed by the string, then double greater-than signs –so the heart of the text was omitted and therefore the comment was rendered useless. I am sorry for mixing things up by that mistake.
After noticing how my comment/question was parsed, I reintroduced the same remark with the same knee-jerk “don’t substitute a subset of $PATH when you only want to append/prepend to it” reaction that I had after imbibing your generous, step-by-step howto here. Thank you again for it.
I see now that indeed we are talking about the PKG_CONFIG environment variable rather than $PATH, which I kind of suspected but did not make register. I certainly would like to see this process Wikified rather than clutter up the weblog, so please cleanse the comments as soon as you see fit.
I have an ulterior motive here:
I would like to ask whether or not compiling from the WB source (still) requires a successful compilation of the mysql-gui-tools source, and for whatever pointers you might share regarding this substantial hurdle for my recent reinstallation of FC9. Might you profile the WB-ready package configuration for FC9?
Thanks for everything here, Colin!
Hi!
Well, it shouldn’t have to be on a Wiki – this stuff should just work. Its cluttered up on a weblog, because its still in alpha and well, doesn’t work as well yet :P
Compiling WB from source does not require you to have mysql-gui-tools. They’re independent.
Now, I’m in a rock and a hard place. 5.1.1-alpha is well, mostly outdated by today’s standards. We’ve hacked on the tree much, and I’ve sent in a few patches to ensure more goodness with gcc-4.3. However, the source tree is *drumroll* internal only.
The workbench team is working on how to start sharing this code, as soon as possible. Its a priority to get it on Launchpad at some stage.
I wish I can give you more concrete answers, but there’s no point in me promising something that I have no ability to deliver on (I’m not involved in the process)
Hope this helps… Watch the workbench blog as well as mine if you’re interested in the future, post-alpha
Thanks for trying the software (or trying to) as well
I just purchased WB SE and really like it. Am looking forward to seeing it running on Linux and particularly on Fedora. Great job!
Any news on the Mac version?
The line with
‘ln -s /usr/include/ctemplate google’
should read as
‘ln -s /usr/include/ctemplate /usr/include/google’
if my failure to do ‘bash autogen.sh’ until creating the symbolic link is any proof. Just taking notes here as much as anything, since I imagine a number of people will continue to look at this helpful recipe/guide but hit that snag.
Thanks again.