PgSQL: preserve toolchain LDFLAGS on macOS by skearnes · Pull Request #9285 · rdkit/rdkit (original) (raw)

The previous set(CMAKE_EXE_LINKER_FLAGS ...) replaced the variable wholesale, which clobbers any toolchain-supplied linker flags. In particular, conda-forge's clang_osx-64 / clangxx_osx-64 packages set -stdlib=libc++ -L${PREFIX}/lib -Wl,-rpath,${PREFIX}/lib via CMAKE_EXE_LINKER_FLAGS. Losing those flags causes the postgres extension link to pick up the wrong libc++ and fail to resolve ABI-tagged symbols on libc++ 19+:

[ 94%] Linking CXX executable rdkit.dylib
Undefined symbols for architecture x86_64:
  "VTT for std::__1::basic_stringstream<...>"
  "vtable for std::__1::basic_stringbuf<...>"
  "vtable for std::__1::basic_stringstream<...>"
  "vtable for std::__1::basic_istringstream<...>"
ld: symbol(s) not found for architecture x86_64

The missing symbols carry the [abi:ne190107] ABI tag introduced by libc++ 19+ — references that only resolve against the conda-forge libc++, not the system one the link was falling back to.

Append to CMAKE_EXE_LINKER_FLAGS instead so the toolchain flags survive. The other rdkit .dylibs in the same build are linked via the standard cmake toolchain path and were never affected.

Verified by building rdkit-postgresql on osx-64 + osx-arm64 via the conda-forge feedstock (https://github.com/conda-forge/rdkit-feedstock) with this fix applied as a downstream patch.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

greglandrum pushed a commit that referenced this pull request

May 29, 2026

The previous set(CMAKE_EXE_LINKER_FLAGS ...) replaced the variable wholesale, which clobbers any toolchain-supplied linker flags. In particular, conda-forge's clang_osx-64 / clangxx_osx-64 packages set -stdlib=libc++ -L${PREFIX}/lib -Wl,-rpath,${PREFIX}/lib via CMAKE_EXE_LINKER_FLAGS. Losing those flags causes the postgres extension link to pick up the wrong libc++ and fail to resolve ABI-tagged symbols on libc++ 19+:

[ 94%] Linking CXX executable rdkit.dylib
Undefined symbols for architecture x86_64:
  "VTT for std::__1::basic_stringstream<...>"
  "vtable for std::__1::basic_stringbuf<...>"
  "vtable for std::__1::basic_stringstream<...>"
  "vtable for std::__1::basic_istringstream<...>"
ld: symbol(s) not found for architecture x86_64

The missing symbols carry the [abi:ne190107] ABI tag introduced by libc++ 19+ — references that only resolve against the conda-forge libc++, not the system one the link was falling back to.

Append to CMAKE_EXE_LINKER_FLAGS instead so the toolchain flags survive. The other rdkit .dylibs in the same build are linked via the standard cmake toolchain path and were never affected.

Verified by building rdkit-postgresql on osx-64 + osx-arm64 via the conda-forge feedstock (https://github.com/conda-forge/rdkit-feedstock) with this fix applied as a downstream patch.

Co-authored-by: Claude Opus 4.7 (1M context) noreply@anthropic.com

skearnes added a commit to regro-cf-autotick-bot/rdkit-feedstock that referenced this pull request

May 30, 2026

…g tests

v2026_03_3 includes the three component-tagging/linker fixes these patches backported, so they are dropped:

• dev-component-tagging.patch (rdkit/rdkit#9287)
• rdkit-postgresql-osx-linker-flags.patch (rdkit/rdkit#9285)

rdkitpython-component-python.patch (rdkit/rdkit#9288) was never on this branch and is also upstream now, so nothing to drop there.

Also adds the test assertions from the closed conda-forge#228 that never merged: librdkit-dev must NOT ship rdkitpython-config.cmake (it is python-version coupled), and the rdkit (python) output MUST ship it.

Verified the four remaining patches apply cleanly in sequence against the v2026_03_3 source tarball.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})