Date: Tue, 28 Nov 2017 16:26:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 223943] ports-mgmt/portupgrade and the ICU-libraries Message-ID: <bug-223943-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223943 Bug ID: 223943 Summary: ports-mgmt/portupgrade and the ICU-libraries Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: bdrewery@FreeBSD.org Reporter: mi@ALDAN.algebra.com Assignee: bdrewery@FreeBSD.org Flags: maintainer-feedback?(bdrewery@FreeBSD.org) Every time portupgrade replaces the ICU port, the binaries trying to use libicuuc.so.* and other bits installed by that port break. This is probably because the ICU port still uses not only major, but also t= he minor library versions -- something, portupgrade is not handling well. For example, although I have the libicuio.so.59.1 in ${LOCALBASE}/lib/compat/pkg/ now, it is not being found by anything, because other binaries look for it with just .59 (without the .1). For example: Shared object "libicuuc.so.59" not found, required by "libQt5WebKit.so.5" Once I create the necessary symlinks, things begin to work again. Also, and probably for the same reason, portupgrade misses these other pack= ages -- and fails to rebuild them when upgrading ICU -- even when run with `-r -= R`. This problem may be happening with other ports as well, but ICU is used by = so many, lots of people are affected... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223943-13>