It may depend on your needs in terms of performance and ease of integration into an existing framework.
If this is for your engine’s tool chain, performance isn’t as important and integration will be based around the GUI library itself, not the other way around.
In that case I would recommend Qt (they want you to pronounce it as “cute”, but I don’t think that is very cute so I pronounce it “Kyu Tee”).
It has OpenGL controls each with their own contexts that should work fairly easily with your engine, although you may have to work around the fact that your resources will not be shared between contexts. You will have this problem anyway though depending on how you initially structured your engine, but it can generally be managed.
If you are looking for a GUI that would actually go inside your engine and shipp with a game, I would suggest to make your own custom one.
None of the existing ones are really made for that nor are they likely to play nicely with your engine.
For example, Crazy Eddies GUI System was designed for use in games, and is cross-platform with OpenGL support, but if your engine is high-performance then you are doing render-state redundancy checks etc. inside your own wrappers to OpenGL functions. If this library is calling OpenGL functions directly it is going to cause problems with your redundant state tracking.
They do offer a NULL renderer but I have no idea how hard it is to hook it up into your own custom renderer. It may be easier again to write your own GUI, which really doesn’t take a lot of work and can be quite fun. You also have the advantage of being in full control.
L. Spiro