Similar to Microsoft's CLS, the Java Bytecode that the Java virtual machine executes gives you the (theoretical) possibility of using libraries from one JVM-targeting language with another JVM-targeting language. For example, Java libraries can be used in Scala, which IMO is a much better language than Java itself. Libraries written in Scala could be used in Clojure, or in Jython, or in one of these languages.
However, although interoperability is theoretically possible because of the common byte code to which all these languages compile, it is said (my personal experience is fairly limited) to sometimes be complicated to actually get it working.
Another, in the context of your question probably equally big drawback is, that using libraries from other languages often forces you to program in that languages style - and consequently "rip" you out of the style of the language you are actually programming in. For example, due to the lack of closures/anonymous functions and higher-order functions, Java libraries often don't have "nice" interfaces in the functional programming sense. Scala libraries, on the other hand, are usually written in a functional way.
Another way of addressing your problem are multi-platform languages such as Haxe.
Haxe can be compiled to all popular programming platforms with its
To be fair, I don't have any experience with Haxe, so all I can do is conjecture. That said, I see this approach as a double-edged sword. On the one hand, it allows you to implement libraries only once and then compile them to C++, PHP, etc., and use them from their. On the other hand, if you write a client or a library depending on other libraries in Haxe, you are probably limited to Haxe libraries, and, for example, cannot use the highly appraised C++ library Boost.
A similar, although assumably less powerful approach is followed by Apache Thrift.
Apache Thrift allows you to define data types and service interfaces
in a simple definition file. Taking that file as input, the compiler
generates code to be used to easily build RPC clients and servers that
communicate seamlessly across programming languages. Instead of
writing a load of boilerplate code to serialize and transport your
objects and invoke remote methods, you can get right down to business.
I assume that the "out of style" problem mentioned in the context of JVM-targeting languages is actually more general and probably something that makes it difficult to truly achieve what you want. If you specify interfaces arbitrarily general, it is likely that they feel out of place when used in any concrete programming language.
A second problem related to interfaces is which data structures to use as input/output data structures. For example, which data structures should a language-independent sorting library accept and return - arrays, sequences, lists, vectors, streams? And how are these mapped from/to data structures that actually exist in a given concrete language?
Another general problem I can see is performance. A library that is implemented in one language and cross-compiled into another is probably of poorer performance than one that is directly implemented in that language - which is not automatically a problem, but can definitely sometimes be one.