A very common way that people simplify linking C or C++ code to other languages is through the Simplified Wrapper and Interface Generator. For the language runtimes it supports, it's a much easier to understand interface than integrating closely with each different language you wish to ship your library for.
In general, this will mean creating a dynamic library. Loading a dynamic library is a simple task for any runtime, but loading a static module would require modifying the language runtime. For that reason, it simply doesn't make sense to build a static module for either of your cited use cases.
For Python, with your build properly configured, you can ship your library module as a single dynamic library (barring licensing problems with libraries you link to). However, users will typically expect your module to be packaged using the standard Python setup-tools, as a .egg file.
You should be prepared to learn how each respective language community expects third-party packages to be packaged, to make the introduction of your library to them as easy as possible. Conforming to their expectations makes your library appear more professional, better designed, and easier to consider for their projects.
I would recommend, however, spending some time learning more about the Foreign Function Interface of a few different languages, to familiarize yourself with some of the peculiarities that SWIG sometimes can't hide perfectly. For example, passing a value to the other language requires "boxing" the C++ value into a value type, and then incrementing its reference count. SWIG does this for you, but it's sometimes the case where you have no choice but to write or debug some of that code yourself. Being unfamiliar with how those FFI interfaces work will hinder you substantially.
