Kris Kennaway wrote:
> I think something is not quite right in your analysis, because perl
> does not depend on any external perl modules (it cannot, by definition).

I ran into something like this when I was switching from a threaded perl
to an unthreaded perl. It wasn't possible to just use a portupgrade to
rebuild and reinstall all the packages, I needed to uninstall a large
number of them. Basically, every time the port build fell over, I would
need to pkg_which the shared object mentioned in the error message,
uninstall that package and take note of the name then reinstall them all
after everything else worked. I've never encountered this as a result
of a version upgrade though.

Reproducing the problem is pretty simple... build a threaded perl, then
build a bunch of modules that use shared objects, then reconfigure perl
to be unthreaded and force upgrade it. The shared objects will fail to
load and portupgrade of the modules will fall over.

I never reported this as a problem though since it was pretty obvious
why it happened and how to fix it. It was my own fault for playing with
a threaded perl then wanting to change back.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""