Subject: Re: png lib update and gnome-libs
To: Frederick Bruckman <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 05/24/2001 15:38:20
On Thu, 24 May 2001, Frederick Bruckman wrote:
> > Hmm - the 'make update' in png also rebuilt imglib, so I _should_
> > have been OK on that front?
> Not really. Someone's going to try to install "gnome" from binaries on
> the ftp site, and it's going to be all messed up, because some
> packaged binaries will need libpng.so.1.0, and some binaries will need
> libpng.so.2.0, and there'll be no way to distinguish which combination
> of packages will work. Worse, since packages are going to be
> overwritten with identically versioned ones, there may be no way to
> install gnome at all, unless the entire collection is rebuilt from
I understand that case, but in my situation I ran a 'make update'
in graphics/png, so it should have rebuilt gnome-core, which is
what is confusing me.
> As much trouble as it is to walk up the chain from png, bumping
> dependencies and "nb" versions, at least there _is_ a right to handle
> it. For shared libraries which could optionally exist in the base
> system (I'm thinking openssl), there's no right way to do it, unless
> you were to insist on using the pkgsrc version for NetBSD-1.5.x, which
> would really suck.
This happens way to often (at the Wakefield show we found we
had a broken dia package as the packages were built on different
machines and one of the gnome libs had had a major bump between
I completely agree we should have a policy of bumping all
depending packages when a shared library version is changed.
> > As an added bonus rebuilding gnome-libs has made the gnome_segv
> > program work so I can see that gnumeric is getting a segv, but
> > leaves me no closer to a working gnumeric.
> > I'm probably going to have to delete and rebuild all packages on a
> > non production box to see if its upgrade related or a problem with
> > a change in a package.
> Did you see any warnings at link time? Like, "built-in dependency of
> libfoo on libpng.so.1 conflicts with built-in dependency of libbar on
> libpng.so.2"? Does "ldd /usr/X11R6/bin/gnumeric" show any sign of
ldd of gnumeric shows only libpng.so.2, and its now been rebuilt
again with the new gnome-core.
I think there were two issues.
- gnome-core was not rebuilt correctly after png. This _could_
have been an old version of gnome-core left in the work
directory. I'm usually quite reliable at wiping /var/obj/pkg
before rebuilding, but that is the only option I can see that
makes sense (the datestamps in /var/db/pkg/gnome-core*/* were
after /var/db/pkg/png*/*). Hubert's latest 'check versions
on install' changes (Thanks Hubert!) should make sure that
does not happen again... providing we bump versions.
- gnumeric is getting a segv.
Buggered if I know. I'm running a -current kernel with
1.5.1_BETA2 userland on my laptop, and most everything is
-march=pentiumpro, so there could be an issue there (though
it worked find before the png update. I'm building gnumeric
on a 1.5-release kernel & userland machine to see if it
has problems there (and if it does I'll delete every package,
reinstall 1.5 release and disable -march=pentiumpro to get
a real baseline).
David/absolute -- www.netbsd.org: No hype required --