import ibm_db fails on macOS 26 because the bundled clidriver links against GNU libstdc++, which macOS no longer ships at all.
Environment
- ibm-db 3.2.9, installed from PyPI wheel
- macOS 26.6 (build 25G72), x86_64 — Intel, not Apple Silicon, not Rosetta
- Reproduced on Python 3.12.13 and 3.14, in clean venvs,
pip install ibm-db only
What happens
The install itself is clean — the wheel lands and clidriver/ is unpacked under site-packages. The import is what fails:
ImportError: dlopen(.../site-packages/ibm_db.cpython-312-darwin.so, 0x0002):
Symbol not found: __ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm
Referenced from: .../site-packages/clidriver/lib/libdb2.dylib
Expected in: /usr/lib/libstdc++.6.dylib
Demangled, the missing symbol is std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const — GNU libstdc++'s hashtable implementation.
Root cause
/usr/lib/libstdc++.6.dylib does not exist on this system:
$ file /usr/lib/libstdc++.6.dylib
/usr/lib/libstdc++.6.dylib: cannot open ... (No such file or directory)
$ nm -gU /usr/lib/libstdc++.6.dylib | wc -l
1
Apple deprecated GNU libstdc++ in favour of libc++ back in macOS 10.9 and has since removed it; what remains reachable through the dyld shared cache is a stub with essentially no symbols. libdb2.dylib is still built against it:
$ file .../clidriver/lib/libdb2.dylib
Mach-O 64-bit dynamically linked shared library x86_64
Architecture is not the problem here — the dylib is x86_64 and so is the interpreter. This is purely the C++ runtime.
Why this is not the existing macOS reports
There's a long history of Symbol not found on macOS in this tracker (#824, #829, #831, #867, #882 and others), but those are all ___cxa_throw_bad_array_new_length and were generally answered with an Xcode/CLT or Apple Silicon workaround. This is a different symbol from a different library, and the underlying cause is structural: the dependency it needs is no longer part of the operating system, so there is no local toolchain state that fixes it.
Impact
ibm-db is the only DBAPI driver for Db2, and ibm-db-sa is the only SQLAlchemy dialect, so this makes Db2 unreachable from Python on a current macOS. I was adding Db2 to a database-compatibility test matrix and had to stop at the import.
What would fix it
Rebuild the macOS clidriver against libc++ rather than GNU libstdc++. Alternatively, if there's a supported way to get a libc++-linked clidriver today I'd be glad to hear it — I couldn't find one.
I can test a build against this setup if that's useful.
import ibm_dbfails on macOS 26 because the bundled clidriver links against GNU libstdc++, which macOS no longer ships at all.Environment
pip install ibm-dbonlyWhat happens
The install itself is clean — the wheel lands and
clidriver/is unpacked undersite-packages. The import is what fails:Demangled, the missing symbol is
std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const— GNU libstdc++'s hashtable implementation.Root cause
/usr/lib/libstdc++.6.dylibdoes not exist on this system:Apple deprecated GNU libstdc++ in favour of libc++ back in macOS 10.9 and has since removed it; what remains reachable through the dyld shared cache is a stub with essentially no symbols.
libdb2.dylibis still built against it:Architecture is not the problem here — the dylib is x86_64 and so is the interpreter. This is purely the C++ runtime.
Why this is not the existing macOS reports
There's a long history of
Symbol not foundon macOS in this tracker (#824, #829, #831, #867, #882 and others), but those are all___cxa_throw_bad_array_new_lengthand were generally answered with an Xcode/CLT or Apple Silicon workaround. This is a different symbol from a different library, and the underlying cause is structural: the dependency it needs is no longer part of the operating system, so there is no local toolchain state that fixes it.Impact
ibm-dbis the only DBAPI driver for Db2, andibm-db-sais the only SQLAlchemy dialect, so this makes Db2 unreachable from Python on a current macOS. I was adding Db2 to a database-compatibility test matrix and had to stop at the import.What would fix it
Rebuild the macOS clidriver against libc++ rather than GNU libstdc++. Alternatively, if there's a supported way to get a libc++-linked clidriver today I'd be glad to hear it — I couldn't find one.
I can test a build against this setup if that's useful.