Repository navigation
Build failure: error: cannot ‘dynamic_cast’ ‘source’ (of type ‘const class duckdb::CatalogEntry*’) to type ‘const class duckdb::DuckTableEntry*’ #239
Description
What happens?
On a freshly-cloned repo, uv sync --no-build-isolation fails with:
/home/inglesp/tmp/duckdb-python/external/duckdb/src/include/duckdb/common/helper.hpp:265:57: error: cannot ‘dynamic_cast’ ‘source’ (of type ‘const class duckdb::CatalogEntry*’)
to type ‘const class duckdb::DuckTableEntry*’ (target is not pointer or reference to complete type)
265 | D_ASSERT(reinterpret_cast<const T *>(source) == dynamic_cast<const T *>(source));
|
See this gist for the full output, which is too long for this field.
To Reproduce
I ran:
git clone --recurse-submodules https://github.com/duckdb/duckdb-python
cd duckdb-python/
uv sync --no-install-project
uv sync --no-build-isolation
OS:
Ubuntu 22.04, x86_64
DuckDB Package Version:
Latest head (3f1f615)
Python Version:
3.14.0
Full Name:
Peter Inglesby
Affiliation:
Bennett Institute of Applied Data Science, Oxford University
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a source build
Did you include all relevant data sets for reproducing the issue?
Not applicable - the reproduction does not require a data set
Did you include all code required to reproduce the issue?
- Yes, I have
Did you include all relevant configuration to reproduce the issue?
- Yes, I have
Activity
paultiq commentedon Dec 27, 2025
Might be the GCC version -
CI uses
2025-12-27T06:11:50.6002939Z -- The CXX compiler identification is GNU 14.2.1Your gist shows:
-- The CXX compiler identification is GNU 11.4.0inglesp commentedon Dec 29, 2025
Thanks. I'll try to update my build environment.
inglesp commentedon Dec 29, 2025
I've updated to gcc 14.2.0, and get the same error.
Full output
paultiq commentedon Dec 29, 2025
Oh, this is a funny bug:
The bug appears to be a missing include: DuckTableEntry has a forward decl, but isn't included in this particular file... but UNITY masks it.
It doesn't reproduce when UNITY is enabled: Unity combines multiple .cpp files into a single output, so instead of 2196 tiny operations, you get ~500 slightly larger ones, but it sometimes has a small affect (ie: including all the headers).
It's a core bug, but only manifests here because UNITY is disabled for editable builds.
Workaround: change cmake.define.DISABLE_UNITY = "1" to cmake.define.DISABLE_UNITY = "0" in pyproject.toml.
* I normally build with UNITY enabled, it's faster, but comes at a slightly higher rebuild cost when you change 1 file, but that cost has been worth it for me.
** Also: installing ccache or sccache will speed up your rebuild times.
paultiq commentedon Dec 29, 2025
FYI: Building against 1.4-andium may be best.
mainis (usually) broken, as shown by https://github.com/duckdb/duckdb-python/actions/workflows/release.ymlinglesp commentedon Dec 29, 2025
Thanks. Disabling UNITY works for me, as does building against a 11fa60f.
Should I raise an issue against core?
inglesp commentedon Dec 29, 2025
I have ccache installed but it still takes several hours to build on my laptop. I've spun up a VM where it builds in minutes.
evertlammerts commentedon Jan 7, 2026
Hey @inglesp, unless you're willing to deal with sometimes very specific build issues and half working features you should probably not be building from main. Generally speaking you're best off with releases that make it onto PyPI. We upload builds that succeed and pass tests nightly. For main (which will be used to cut 1.5.0 from) the cadence is particularly low atm. v1.4.4devs are much more regular. These are cut from the
v1.4-andiumbranch, which is more likely to build - but it won't include cutting edge stuff that will make it into 1.5.0 of course.Multiple hour builds don't sound right. Mine take about 10 minutes (without enabling unity builds) for a fresh build and seconds for increments. Did you see the development docs?
No need to file an issue in core.
inglesp commentedon Jan 7, 2026
Hey, thanks for the response. I hadn't seen anything in the development docs that suggested building against the andium branch. Am I missing something?
evertlammerts commentedon Jan 7, 2026
No, the link to the docs was meant as a resource for setting up a development env. Not sure if there's an explanation for the meaning of our branches on there. You said a local build takes multiple hours, so thought it might help. I just did a local build of main, and that took ~10 minutes, using only the defaults. This is on a beefy macbook though, and I know that on Windows laptops builds can take very long... on ARM64 especially, since it will cross compile by default unless you explicitly tell UV you want an ARM64 version of Python.
inglesp commentedon Jan 7, 2026
Ah, I see, thanks. Yes, I'd seen those docs and had followed them. I've just tried building on a VM and it completed in ~10 minutes. I'm not going to investigate further!