Skip to content

fix(mysql-connector-cpp): a CN mirror, and a success path that says so - #389

Merged
Sunrisepeak merged 1 commit into
mainfrom
fix/mysql-connector-cpp-mirror-and-return
Sep 11, 2026
Merged

Sunrisepeak merged 1 commit into
mainfrom
fix/mysql-connector-cpp-mirror-and-return

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Two small things, both found while this package kept turning up in the middle of diagnosing something else.

CN mirror

The url was a plain upstream string — which docs/cn-mirror.md describes as the fallback for when nobody has mcpp-res write access. CN users reach GitHub directly and wait. This package sits on the path of the database and graphics members, and a 4.8 MB tarball with no mirror was a recurring tax on exactly the runs where something else was being diagnosed.

mcpp-res/mysql-connector-cpp@26.7.0 now carries the same bytes:

CN http=200  size=4792083
GLOBAL sha  b2299862eefc33fd71c0aac68328305671805fc955e6bd2578ef205c10f98550
CN     sha  b2299862eefc33fd71c0aac68328305671805fc955e6bd2578ef205c10f98550

Same sha the descriptor already declared, so no version's hash moves.

A note for whoever probes this next: gitcode answers HEAD with 401 and GET with 200/206. The already-merged mcpp-res/huxerui mirror behaves identically, and CI's mirror-cn-reachable fetches the body rather than sending HEAD, so this is a quirk of the probe, not of the mirror.

return true on the success path

install() wraps its work in a pcall and returns whatever that yields. Every failure path says return false; the success path ended on an io.writefile and yielded nil. So a working install has been logging

install() result=nil

all along. In a hook log that is otherwise a list of failures, that reads like one — and it did: during the huxerui work it was taken for the cause of a failure whose real origin was an mcpp scanner regression three layers away (mcpp-community/mcpp#606). The value was never wrong; it just never said it was right.

Verification

mcpp xpkg parseparse OK. All five lint checks pass on the descriptor.

The one thing this PR deliberately does not touch: mysql-connector-cpp still fails on the linux llvm leg with undefined libstdc++ symbols (std::__cxx11::basic_string<…>::_M_create, std::_Rb_tree_increment, …). Its install() drives upstream's CMake with the system compiler, so the static libs are built against libstdc++ while that leg links libc++. That is a real incompatibility and a separate change — llamacpp refuses a libc++ toolchain by name via mcpp::cxx_stdlib(), but that API is a build-program one and this is an inline descriptor with no build program, so the same lever is not available here. Left for a change that can argue its own mechanism.

TWO SMALL THINGS, both found while this package kept turning up in the
middle of something else.

CN MIRROR

The url was a plain upstream string, which docs/cn-mirror.md describes as
the fallback for when nobody has `mcpp-res` write access -- CN users reach
GitHub directly and wait. This package sits on the path of anything that
touches the graphics or database members, and a 4.8 MB tarball with no
mirror was a recurring tax on exactly the runs where something else was
being diagnosed.

`mcpp-res/mysql-connector-cpp@26.7.0` now carries the same bytes:

    CN http=200  size=4792083
    GLOBAL sha  b2299862eefc33fd71c0aac68328305671805fc955e6bd2578ef205c10f98550
    CN     sha  b2299862eefc33fd71c0aac68328305671805fc955e6bd2578ef205c10f98550

Same sha as the descriptor already declared, so no version's hash moves.

`return true` ON THE SUCCESS PATH

`install()` wraps its work in a pcall and returns whatever that yields.
Every failure path says `return false`; the success path ended on an
`io.writefile` and yielded `nil`. So a WORKING install has been logging

    install() result=nil

all along. In a hook log that is otherwise a list of failures, that reads
like one — and it did: during the huxerui work it was taken for the cause
of a failure whose real origin was an mcpp scanner regression three layers
away. The value was never wrong; it just never said it was right.
@Sunrisepeak

Copy link
Copy Markdown
Member Author

CI: 13/14. The one red check is the pre-existing libc++ mismatch this PR's description already carves out — not a regression from it.

ld.lld: error: undefined symbol: std::_Rb_tree_increment(std::_Rb_tree_node_base*)
ld.lld: error: undefined symbol: std::__cxx11::basic_string<...>::find_first_of(...)
  mysql-connector-cpp   378s  FAIL       (workspace, linux llvm 0/4)

libstdc++ symbols, undefined on the leg that links libc++. The install() hook drives upstream's CMake with the system compiler, so the static libs are built against libstdc++ regardless of what the consumer uses. llamacpp refuses a libc++ toolchain by name via mcpp::cxx_stdlib(), but that is a build-program API and this is an inline descriptor with no build program — the same lever is not reachable from here, which is why this PR does not reach for it.

The same log carries the other half of the change working:

install() result=true

That line used to read result=nil on a successful install, which is what made it look like a cause during the huxerui work. It now says what it means.

@Sunrisepeak
Sunrisepeak merged commit 9ea3271 into main Sep 11, 2026
13 of 14 checks passed
@Sunrisepeak
Sunrisepeak deleted the fix/mysql-connector-cpp-mirror-and-return branch September 11, 2026 11:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant