libutil.so.7 not found

rtwingfield

rtwingfield

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.)
 
Last edited by a moderator:
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.
 
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.
 
You must log in or register to reply here.
Back
Top