pkg_libchk

[talsamon]

Every time I run pkg_libchk it shows a lot of non-existent libraries any programs are missing, or one library missing by a lot of programs. Today I am compiling www/firefox, mail/hunderbird and www/libxul . A few days ago, www/webkit-gtk2. This ports takes a lot of time to compile. Now pkg_libchk shows: these ports and other ports missing libicuuc.so.52 and libicudata.so.52.

I never had to recompile so many ports as now. I think it's since PKGNG. I hate it.

Why? It was never a problem before.

 

[kpa]

No, it has absolutely nothing to do with PKGNG. All the same problems existed when the old package format was in use and were tenfolds worse. Try a little simple logic and start from thinking what PKGNG is, it's just package format plus the tools to create the packages. How could it have anything to do with shared library problems? You do understand how dynamic linking works in UNIX and UNIX-like operating systems?

 

[talsamon]

You're right, that could not have anything to do with PKGNG. And what's wrong? Do I do something wrong or is it something with the system, or anything else? What I do not understand, I updated these programs, why couldn't they find the right libraries???

 

[kpa]

It's what is known as "DLL Hell". Basically when a port that provides a shared library is updated, every single port that uses that library needs recompilation so that the binaries (programs and their own shared libraries) get linked against the new version of the library *). The process of detecting every single port that needs recompilation is not yet automated by the ports(7) infrastructure. That's the reason for the UPDATING entries that tell you to run portmaster -w -r icu (for example) to recompile all the "reverse dependencies" of a port that was just updated. If you update just the port that just had a shared library version bump you will get just the kind of errors you are now seeing.

Unfortunately even the UPDATING instructions are not enough to cover all difficult cases because portmaster(8) and the other similar tools are operating on the "live system". The only surefire way to avoid any port update problems at the moment is use a package builder like ports-mgmt/poudriere that builds the ports in a totally clean environment, separate from the "live system".

*) Note that the dependencies between the installed ports and packages as recorded in the package database only reflect the dynamic shared library dependencies that are in the binaries and shared libraries. The shared library dependencies are uneditable in a binary or a shared library, a full recompilation and linking is always needed to adjust those dependencies.