finding dependents of a shared library

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

finding dependents of a shared library

rjvbertin
Hi,

Not really MacPorts related, or rather, this goes beyond:

The question came up "how to find any/all binary files that link to this or that shared library". I think we discussed this a bit before before, I remember describing my kludgy way to answer that question for a library provided by a port (move it aside and then run a verbose rev-upgrade to see what errors I get).

AFAIK the way rev-upgrade works is
- rev-upgrade scans a list of all supposed-to-be-present binary files
- for each file on that list it determines the list of dependencies (or list of deps provided by active ports)
- for each of the dependencies on that list it checks if the file is present (and will load).

It seems to me that we thus have the basic features available to write a SpotLight importer for MachO binary files which would enter this reverse dependency information in the SpotLight database. IOW, associate the dependent to each found dependency.

Does that sound like a feasible and useful idea (and one that won't overload SpotLight)? Or maybe someone already invented this wheel (wouldn't that be nice :))?

Thanks,
René
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: finding dependents of a shared library

Clemens Lang-2
Hi,

On Wed, May 24, 2017 at 04:23:15PM +0200, René J.V. Bertin wrote:
> AFAIK the way rev-upgrade works is
> - rev-upgrade scans a list of all supposed-to-be-present binary files

Correct.

> - for each file on that list it determines the list of dependencies
>   (or list of deps provided by active ports)

The part outside of parentheses is correct, the part inside isn't.
rev-upgrade doesn't care whether the dep is provided by an active port,
it just makes sure the library is there and will load.


> It seems to me that we thus have the basic features available to write
> a SpotLight importer for MachO binary files which would enter this
> reverse dependency information in the SpotLight database. IOW,
> associate the dependent to each found dependency.

Yes, that could be done. The relevant code is in src/machista1.0, with
Tcl bindings and in C. I don't see a particular reason why we should
involve Spotlight there, especially considering Apple's tendency to
break APIs whenever they see fit and introduce a maintenance burden.
A SQLite database would do just fine.


> Does that sound like a feasible and useful idea (and one that won't
> overload SpotLight)? Or maybe someone already invented this wheel
> (wouldn't that be nice :))?

Most of this is done, really. You just need the file iteration, invoke
libmachista/machista1.0 APIs, run over the results and put them into
some database.

I'm not aware of a finished tool that does it.

--
Clemens
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: finding dependents of a shared library

rjvbertin
Clemens Lang wrote:

Hi,

> The part outside of parentheses is correct, the part inside isn't.
> rev-upgrade doesn't care whether the dep is provided by an active port,
> it just makes sure the library is there and will load.

Ok. Not sure if that changes anything for what I had in mind :)

> Tcl bindings and in C. I don't see a particular reason why we should
> involve Spotlight there, especially considering Apple's tendency to
> break APIs whenever they see fit and introduce a maintenance burden.
> A SQLite database would do just fine.

The only point in involving Spotlight would be to have a common interface that
works, with a common set of configurable options like where to search and where
not. And of course the automatic "only-what's-changed-updating" part. That sort
of thing is usually the most expensive aspect to develop, and what keeps me from
sitting down and writing something myself. For now :)

> I'm not aware of a finished tool that does it.

No, I haven't found anything either. A bit surprising in a way, it sounds like a
tool that could be quite useful for distribution maintainers and OS developers.

R

_______________________________________________
macports-dev mailing list
[hidden email]
https://lists.macosforge.org/mailman/listinfo/macports-dev
Loading...