This is a patch adapted from the one in Debian written by Joost Yervante Damad. It causes the build process to spit out a library called libGLEWmx, instead of libGLEW, when built with GLEW_MX=1...on Linux, anyway. Joost's version also patched Makefile.kfreebsd and Makefile.gnu . It's trivial to patch as many of the Makefiles as you like, but I'm working with Fedora and so only needed to change linux, and I wasn't sure entirely how many of the target arches it would be appropriate for the library to be renamed on.
The usefulness of this is that the MX support, by your admission, breaks API compatibility, so responsible distributions cannot really turn on the MX support so long as it just spits out a library called libGLEW.so.1 , as it's not actually ABI compatible with previous libGLEW.so.1's. With this change, distributions can ship a libglew-mx package containing libGLEWmx.so.1 alongside the libglew package containing libGLEW.so.1, and packages that want to build against the MX-supporting libglew can just build with -lGLEWmx instead of -lGLEW. The patch also produces a glewmx.pc to aid in this. (This bit is implemented somewhat dumbly: glewmx.pc and glew.pc are both always generated in build stage, but the appropriate one is installed at install time).
Joost's patch introduced a libsonly build target which builds only the library. I went further down this patch by splitting the install phase into two stages, install-libs and install-bin, and made the standard install target perform both of them: this allows a distro to do 'make install' then 'GLEW_MX=1 make install-libs' to install libGLEWmx without overwriting non-lib stuff (currently only the 'glewinfo' tool) from the non-MX build with the one from the MX build. (You could always just do the MX install and then the non MX install, but that's a bit fragile, this seems more elegant).
This may well need some refinement, but I wanted to submit something material at least rather than just the idea of splitting the build. This is practically useful for me for packaging Unity in Fedora; it requires the MX-enabled glew, and Ubuntu uses the Debian patch and links against libGLEWmx, so it makes sense for Fedora to do much the same; rather than Debian and Fedora implementing the same downstream patch it seems to make sense to send it back upstream.
The obvious things I can see are to figure out if targets beside Linux and FreeBSD should have this change. I also didn't bother including a static glewmx.pc , as Joost did...I don't quite see why the static glew.pc exists at all as it seems like it's always going to be regenerated from glew.pc.in when you run make. So for glewmx.pc I didn't bother.
The patch is dependent on a couple of other Fedora patches (they change lines close by, so the patch won't apply unmodified to upstream source, though the changes are small). See http://pkgs.fedoraproject.org/gitweb/?p=glew.git;a=tree patches glew-1.5.2-add-needed.patch and glew-1.5.2-makefile.patch . These may be suitable for upstreaming too, in fact.