Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Mar 2008 11:16:29 -0800
From:      Stephen Hurd <shurd@sasktel.net>
To:        Kris Kennaway <kris@FreeBSD.org>
Cc:        ports@freebsd.org, stable@FreeBSD.org, Steven Hartland <killing@multiplay.co.uk>
Subject:   Re: portupgrade, recommended by 7 release notes, breaks perl
Message-ID:  <47C9AB8D.3020608@sasktel.net>
In-Reply-To: <47C95FBC.1030907@FreeBSD.org>
References:  <00ab01c87b64$29c7b8c0$b6db87d4@multiplay.co.uk> <47C95FBC.1030907@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C9AB8D.3020608>