Normally things are done in this order:
- Cryptographers come up with new ideas for algorithms and publish them.
- Other cryptographers break them, then fix them again, and so on, until there is an algorithm which can be deemed "secure enough" by virtue of having survived the process relatively unscathed.
- A cryptographer with a practical mind writes a specification which tells how to implement the algorithm, minding details like endianness.
- A developer follows the specification and writes code.
Sometimes steps 3 and 4 are done in the reverse order: someone writes the code, and only then the specification is written to match the arbitrary conventions that the original developer decided upon (usually on a whim: e.g. you will get little-endian or big-endian encoding depending on what was simplest to do in the programming framework of that developer).
Oblivious transfer is a concept, and actual algorithms are somewhere between steps 1 and 2 right now. So no usable library: if you find an implementation, then it will be part of some research project (a cryptographer using it for research purposes, such as looking for biases and so on), but not an incarnation of a generally agreed-upon "secure" algorithm, ready for the specification step.
Theoretically, oblivious transfer being just an algorithm, it has no value by itself, but only as part of a wider protocol which uses it (and possibly other algorithms) in some way. For anything which looks like production code, you should first find (or define) that overarching protocol, which may use an oblivious transfer primitive, and from the actual protocol structure will depend the actual required characteristics of the oblivious transfer.
In a way, requesting a "library that supports oblivious transfer" is akin to sending a general request for "a combustion engine" without telling whether this is for a boat, a car, a plane or a power plant. It is a bit unanswerable.