# libutil.so.7 not found



## rtwingfield (Jun 5, 2015)

Shared object "libutil.so.7" not found, required by "perl".

I am really tired of running into this apparent impasse.   I've just upgraded an aging v7 FreeBSD platform to *FreeBSD 10.1-RELEASE-p10*.  (stepped up through v8 and v9 to v10 in the past 24 hrs.)  Now, while trying to rebuild all installed ports (as recommend), utilities and management tools such as `portmaster`, `portupgrade`, `pkg info`, etc. all seem to break, and a common thread is the complaint regarding libutil.so.7.  I have searched this Forum, and the _Daemon Forums_, Googled the 'net, and basically find nothing except a lot of questions, and an obscure suggestion that libutil.so.8 is now part of the base.  Regardless, where is this _thing_ made?  Of what port or package is it a component?  Is this "libutil" a general purpose suite of functions, common to numerous applications?  I only find these on the system:

/usr/local/lib/compat/libutil.so.5
/lib/libutil.so.9
/lib/libutil.so.8
​
I seem to be in _Catch-22 World_.  Apparently I can't `make` and `install` these port management tools without it.

(edit)
I just mounted the root and /usr partitions on the old v7 OS drive and found

/usr/local/lib/compat/libutil.so.5
/lib/libutil.so.7
​
I copied the /lib/libutil.so.7 object to the same location on the v10.1 system.  We'll see what happens.

(edit)
. . .it worked -- the Perl install ran to completion; however, the installation looks like a hybrid of v 5.8.9 and v5.22.   (I'll post another thread.)

Regarding the /lib/libutil.so.7 file, apparently the .7 version existed in the FreeBSD v7 file system.  I migrated the v7 files to a terabyte HD and proceeded with the upgrade through v8 and v9 to v10.1.  Somewhere along the way, the upgrade deleted the .7 version of the  /lib/libutil.so.7 file.  (FYI, I've kept the old 60GB HD with FreeBSD v7 and it is still installed and mountable and/or bootable on the platform.)


----------



## SirDice (Jun 5, 2015)

As this machine was upgraded from an old install, instead of upgrading, I'd make a list of the things that are installed and remove everything. Then build the list on the "clean" machine. That way you won't fall into a dependency hell and the system will be able to build without having to worry about old libraries lingering around or not updating in the correct order.


----------



## rtwingfield (Jun 5, 2015)

Thought of that, but it's a long list.  That's why I'd at least like to be able to run something like `pkg info`.  As for cleaning out the deadwood, the Perl v5.8.9 no longer has a port from which `make deinstall` can be run.  I'm a little antsy about just `cd'ing` to a directory and whacking something . . .not knowing what else may depend on depreciated objects, etc.  I read in the docs or _Handbook_ . . .somewhere that the `portupgrade` system can recursively examine the make files and determine dependencies, versions, etc., but I have found this to be undependable.  I've written make files for large complex systems.  If you're not writing the make file while you're developing the application code, then the after-the-fact challenge can be daunting at the least, and most programmers don't do that . . .often documentation is an afterthought, and so goes the make file, too.  Easy then to overlook details and nuances.

Thanks for the recommendation.


----------



## SirDice (Jun 5, 2015)

A pkg-delete(8) should be able to remove it. That's actually what `make deinstall` does..


----------

