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>