Closed fredclausen closed 7 months ago
That issue not only describes the problem but has also been closed because it was fixed and published under a semver-compatible release. Is this a duplicate and stale report in the wrong repository?
Perhaps you still have zeromq-src
bound to an older version via Cargo.lock
locally. Try running cargo update -p zeromq-src
to make sure it's on version 0.2.6
.
One notable exception is cross-compiling; I submitted a followup fix to the repository (https://github.com/jean-airoldie/zeromq-src-rs/commit/21056e972a91b96bc98969fe76626585695410ed) that only seems to have made it into the semver-incompatible 0.3.0
release.
For that action in this repository is needed. I'll push that soon.
That issue not only describes the problem but has also been closed because it was fixed and published under a semver-compatible release. Is this a duplicate and stale report in the wrong repository?
Perhaps you still have
zeromq-src
bound to an older version viaCargo.lock
locally. Try runningcargo update -p zeromq-src
to make sure it's on version0.2.6
.
I was confused because I knew upstream had fixed the issue, and I thought this library was locked in to an older version. I was wrong, and forcing cargo to update fixed it. Thank you for that!
For completeness, if you believe an issue has been fixed upstream and action is needed in a downstream repository to consume it, do mention so from the get-go :)
For that action in this repository is needed. I'll push that soon.
Version bump pushed in #386.
The issue/discussions here describes the issue. Basically, compilation fails because glibc 2.38 includes
strlcpy
inString.h
and then attempts to redefine it.