Subject: Re: Shared object not found - but all dependencies are ok ?!
To: Jeremy C. Reed <>
From: Pavel Cahyna <>
List: tech-pkg
Date: 01/13/2005 10:04:24

> > Now, I tried to start snx101view and it printed:
> > Shared object "" not found
> ...
> > So, the imlib dependency is satisfied, but the program actually does not
> > find the library that it needs.
> Yes, these open-ended dependencies cause problems. I often have same
> problem when installing a library package that is newer than the package
> needing it!
> > Could this be fixed, please? I don't see what the dependencies are for if
> > they don't guarantee that a program will run when they are satisfied. At
> > least for shared libraries which are the most common reason for
> > dependencies this should work.
> >
> > Couldn't this bye done by embedding the library version in the package
> > name, like in Debian? (see
> >
> For example, I see Debian's cracklib2 version 2.7-8.5. It installs
> /usr/lib/

actually /usr/lib/ (/usr/lib/ is just a
symlink). The SONAME is

> libmm11 1.1.3-6.1 installs /usr/lib/

the SONAME is

> libssl0.9.6 installs /usr/lib/ and
> /usr/lib/

the SONAME is and

> libncurses5 installs /usr/lib/, /lib/,
> /usr/lib/ and /usr/lib/

SONAMEs are , , and

So, the name of the package always embeds the version number from the
SONAME at the end. 

> Do you have any examples, because that webpage doesn't show any.

I don't understand what are you saying... the examples you just gave are
not enough?

> The problem with pkgsrc is that on different platforms the SONAMEs may be
> different.

Ah, damn.

> Does anyone have any suggestions on how a BUILDLINK_DEPENDS
> (or BUILDLINK_RECOMMEND) can be dynamically set to the correct package
> name?
> Does anyone have any ideas on how to get the PKGNAME to dynamically add
> one SONAME number to it?
> But then we would still have the problem where we can't go back in time
> and "make install" a package to generate the old SONAME (like you needed).

I wouldn't have this problem. pkg_add would tell me that I didn't have the
imlib10 package that is needed, and either I would go and search for it
(and find it, because it will be part of the same bulk build package
archive that I downloaded snx101util from). Or a smart conflict/dependency
resolution tool like apt-get would do it for me.

> We could start having separate packages for each SONAME, but that will be
> come a maintenance problem.
> Improving pkg_add to correctly verify the PROVIDES versus REQUIRES before
> installation is any idea. I am not sure what it can say though -- "This
> package needs ..... I don't know what the package is called. Sorry."

Ah, I see that the library names are recorded as REQUIRES. But maybe they
should be without full absolute paths?

> A third idea is to have an improved pkg installation tool that uses a
> database of all the metadata about all available packages. Then when a
> package is to be installed, the metadata can be consulted. It needs
> libfoo.1 and so it can automatically update all packages as necessary or
> say there is a problem long before anything is installed. (It can also
> download everything correctly and know it will work before any
> extractions.)

Yes, something like apt-get or various frontends like aptitude...

Most of Linux distributions seem to have a "dumb" package installer which
can just install a package from a file and record it as installed (and
deinstall it, too), like dpkg and rpm, and a "smart" conflict and
dependency resolution system like apt-get or yum (which call the former).
This seems like a good policy because you can experiment with different
dependency resolution tools.

Bye	Pavel