ports/120517: Portupgrade bumped version of libicui18n, stored old version in compat/pkg, but linker doesn't find it: no minor?
Andrew Reilly
andrew at areilly.bpc-users.org
Mon Feb 11 03:10:01 UTC 2008
>Number: 120517
>Category: ports
>Synopsis: Portupgrade bumped version of libicui18n, stored old version in compat/pkg, but linker doesn't find it: no minor?
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Feb 11 03:10:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Andrew Reilly
>Release: FreeBSD 7.0-PRERELEASE amd64
>Organization:
>Environment:
System: FreeBSD duncan.reilly.home 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Sun Feb 10 11:34:27 EST 2008 root at duncan:/usr/obj/usr/src/sys/DUNCAN amd64
Machine is an Athlon64-X2 with 3G RAM
>Description:
Yesterday, after updating FreeBSD itself (as in uname
above), I did my usual ports csup/portupgrade exercise.
As usual, I portupgraded with --batch -akrR, but badness
ensued, and many GNOME componenets broke with the
following error message (or like it) in
.xsession-errors:
/libexec/ld-elf.so.1: Shared object "libicui18n.so.36"
not found, required by "gconftool-2"
Now, portupgrade is *supposed* to preserve shared
libraries, and indeed /usr/local/lib/compat/pkg contains
libicui18n.so.36.0, but it seems that the dynamic loader
doesn't want to use that when asked for
libicui18n.so.36, and I don't know why. I thought that
elf shared libraries didn't have minor numbers: what's
with the .0 anyway? I've just looked into
lib/compat/pkg and it seems that there are quite a few
libraries that have both two and three version
components, although most just have one.
The flip side of this situation is that the -r part of
the portupgrade doesn't seem to have worked: there
should not *be* any dependencies on libraries in
lib/compat/pkg, because those dependencies are supposed
to have been rebuilt against the new versions. I'm
currently running a portupgrade -r -f 'icu-*', and it's
certainly building a *lot*, so hopefully that will do
the job. I think that it should have done the job
already, though.
>How-To-Repeat:
Have GNOME installed as of last week. Upgrade ports
tree to include the change to icu-3.8.1 from icu-3.6.0,
and portupgrade --batch -akrR.
>Fix:
Dunno if this is a problem with /libexec/ld-elf.so.1 or
an incorrect library specification in the affected ports
(gnome-terminal broke as well as gconftool-2: I'm
guessing that most GNOME things would have broken, but
I'm forcing a re-build now, so I'll never know) or a
shortcoming of the portupgrade library backup process.
I suspect that a fix could be applied in any of those
places. The work-around that I'm doing is to force the
re-building of dependent ports.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list