__int128 is not part of the standard. Even if a compiler supports it, it's bad style to use it directly that way. Identifiers starting with two underscores, or an underscore and an uppercase letter, are by definition reserved for the compiler / library, i.e. the identifier alone tells you "back off, dude, this is not for you".
In the header <cinttypes> you will find the types intmax_t and uintmax_t, which - also by definition - represent the largest integers a compiler will support. If these are smaller than 128 bit (sizeof( intmax_t ) < 16), then that is too bad, and you cannot do much about it. (You might even find int128_t and uint128_t in <cstdint>. Cannot find my copy of the C standard right now whether a platform supporting 128-bit integers is actually required to provide those two.)
Having your project depend on the existence of a native 128-bit integer is bad design anyway if you are aiming for portability (to a RaspPi, for example), as most platforms are bound to not support those natively. So, you should probably test for the width of intmax_t as described above, and keep an alternative implementation ready that relies on third-party arbitrary precision arithmetics. BjB already mentioned GMP. There's also TTMath, and probably others.