Well clearly some aspect about your library has to be dynamic, meaning its behavior is dependent on some external aspect, whether that be the name of a library to add or the name of a class to instantiate.
It really is only a question of what aspect of your will be dynamic.
I've run into this type of problem before using Java, and since Java is not platform specific, you could run it potentially on any operating system that supports Java. Of course not every functionality is available in every operating system, meaning you need to be able to intelligently adapt your program according to the operating system.
The approach I took was to use classpath as the dynamic external factor. According to the operating system present, it would include the main library (jar) as well as an additional library written specifically for that particular operating system in which it was installed (the batch file launching the program is almost certainly platform-specific anyway, so what better place to place this particular platform-specific change?). Java specifically has a handy ServiceLoader designed to allow other libraries to implement interfaces in your main jar.
Your main library can call them as an interface without knowing who or how it is implemented, and your add-on library can perform timing mechanisms if available. If no interface implementation is available, have a fallback mechanism for when timing mechanisms are not possible.
You may not be using Java, but this idea is relatively easy to extend to other languages with a bit of reflection. Use a parameter passed to the program as a name of the implementation class for your timing mechanism. If a parameter is passed, try to instantiate a new instance of it dynamically and you're set to go. Just be sure to include a reference to your external library when you launch your program.
You'll most certainly want to separate the main functionality from the plugin, but if done in this way, you could easily upgrade/extend the plugin without ever having to touch the main program.