It's unfortunate, but unavoidable; there's a couple of flag days coming up
after the 2005Q1 branch that will cause some shared objects to change their
names.  (These are fixes to libtool in a couple different places.)

* gcc3 and gcc34 on all platforms:  The bundled libtool does not produce
  shlibs (and in some cases, tries to produce shlibs and fails) on some
  platforms because it does not contain many platform fixes collected by
  pkgsrc.  I will be changing these packages to pull in the libtool support
  of devel/libtool, regenerating configure scripts and patches.

  This change will happen some time in mid to late April.

* libtool on DragonFly:  The "version_type=freebsd-elf" chosen by this port
  has the same breakage I fixed for all other platforms some time ago.

  This change will happen within a week after the 2005Q1 branch is cut, as
  part of the upgrade to libtool 1.5.14.

Both changes will alter the .so.N shared object names on the indicated
platforms, which will mean that binary packages built before the change will
not be compatible with ones built after the change.  Bulk binary-package
builds from pkgsrc-current will probably be wiped out from ftp.netbsd.org
and repopulated from fresh, clean builds to reflect the changes.

However:

Thanks to the .la architecture of libtool, those building from source will
have a stopgap fix in the meantime.  So long as "make replace" is NOT used
on dependency library packages already in use, packages will still be able
to link with before-the-change dependencies using the old shared object
names.

You'll still need to rebuild the whole tree rooted at the dependency when
the dependency is finally updated, but that may be done at your leisure,
rather than "must be done immediately".

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>