Conversation
frr links against libcrypt (crypt(3)). On musl this symbol lives in
libc itself, but glibc ships it in a separate libcrypt.so.1, so the
package fails the library dependency check on glibc targets:
Package frr is missing dependencies for the following libraries:
libcrypt.so.1
Add the conditional +USE_GLIBC:libcrypt-compat dependency, matching
the convention already used by other packages that call crypt(3)
(perl, python3, stress-ng, screen, dante, ...). This is a no-op on
musl builds.
Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
This does not look good. |
|
Good catch, thanks. That failure is a pre-existing frr-zebra packaging bug, independent of the libcrypt change: I've pushed a second commit switching that install line to Happy to split this into its own PR if you'd prefer to keep the two fixes separate. |
| PKG_NAME:=frr | ||
| PKG_VERSION:=10.6.1 | ||
| PKG_RELEASE:=1 | ||
| PKG_RELEASE:=3 |
There was a problem hiding this comment.
nit (optional, not blocking): both commits bump PKG_RELEASE, so release 2 is never published on master. One bump per PR is enough; you could drop the second bump and keep PKG_RELEASE:=2.
Generated by Claude Code
There was a problem hiding this comment.
frr-zebra installs libmlag_pb.so* with INSTALL_BIN, which dereferences
symlinks and copies each match as a regular file. The versioned SONAME
link libmlag_pb.so.0 -> libmlag_pb.so.0.0.0 is therefore lost, and the
package check fails:
frr-zebra: [fail] Library /usr/lib/libmlag_pb.so.0.0.0 has SONAME
'libmlag_pb.so.0' but no corresponding symlink was found in /usr/lib
Install the library with $(CP) instead, which preserves the symlinks,
matching how libfrr.so*/libmgmt_be_nb.so* are already installed in the
base frr package.
Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
40620ca to
05421cd
Compare
|
Good point — collapsed to a single |
|
frr-pythontools has no executable that reports the package version: /usr/sbin/frr-reload just runs 'frr-reload.py --reload', which needs running daemons, so the generic CI version check fails with "No executables in the package provided version". Add a version test override. Since it replaces the generic version probe for every frr subpackage, keep checking --version for vtysh, mgmtd, watchfrr, zebra and all daemons, and skip frr-pythontools, which provides no version information. Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
6642e1f to
765bd7f
Compare
|
Thanks! This failure isn't caused by this PR. I added |
3 participants
Maintainer notice
Maintainer: @openwrt frr maintainers
Description
frr links against libcrypt (
crypt(3)). On musl this symbol lives in libc itself, but glibc ships it in a separatelibcrypt.so.1, so the package fails the library dependency check on glibc targets:This adds the conditional
+USE_GLIBC:libcrypt-compatdependency, matching the convention already used by other packages that callcrypt(3)(perl, python3, stress-ng, screen, dante, ...). It is a no-op on musl builds.PKG_RELEASEis bumped accordingly.Testing
Built
frron a glibc target (powerpc64/e5500) — the missing-dependency error is gone and the package installslibcrypt-compatas a runtime dependency. No change on musl builds.