Obj-C compilation is supported on pretty much everything, as it is part of gcc.
However, the big difference between Obj-C and C++, is that Obj-C also needs a runtime library. This is far less widely supported, and the GnuStep version lags behind the OS X one.
The dynamic nature of Obj-C makes it technically easier to write and compile cross-platform code, but in reality you need to understand exactly what methods are supported by the different target environments, because the compiler isn't going to trap them.
Also, GnuStep, Cocotron and Etoile - the 3 non-Apple Obj-C environments - only have niche take-up amongst Windows and Linux developers. This would reduce the take-up of your library to OS X developers and a very small number of developers on other platforms. Cocotron, for instance, is mostly used by OS X developers looking for a fast port to Windows, not by developers looking for a good x-platform tool.
Another option could be to look at Apple's own open source efforts on macosforge - CoreFoundation, WebKit, clang - or the structure of the OS and other third-party projects that have taken existing code and exposed to Obj-C.
A typical pattern is to have a core C or C++ project, which is then exposed via an Obj-C API.
People have also done the same with C++ and C - i.e. writing OO C++ code, but then exposing it to C via a procedural wrapper at the interface level. You may need to consider this if you expect your code to be linked in to plain C.
In summary - unless writing in Obj-C will simplify the design, and your audience is OS X/iOS developers, I would suggest going with C++ (you say the library needs to be written in an OO language) and then wrapping it with Obj-C at the top.
If it is for OS X/iOS only, I would go with Obj-C.
Another option could be completely ditching the C language requirement and going with a portable OO language like Python or Ruby, where there is a lively community of open source developers.