Larry Vaden wrote:
On Wed, Feb 23, 2011 at 10:11 AM, Les Mikesell lesmikesell@gmail.com wrote:
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
History seems irrelevant to many; if that is the case with the reader, hit DELETE now.
Soon to be 50 years ago, Control Data's SCOPE (simultaneous control of program execution) had 'lgo' (load-and-go) which obviously had to resolve dependencies at run-time, and it produced a load map. It would seem this approach would be useful, but I dunno.
Perhaps it is a tool that Jeff or someone would like to investigate further, perhaps not. IMHO, there's nothing unfathomable about a package reaching out to include other packages.
IFF this turns out to be a useful approach, I would like to thank Dr. James Browne at utexas.edu for his mentoring of our group, particularly for his guidance in scheduling and proving program correctness.
This is not just a simple "find a library" task, sometimes you need to find out what *exact* version of the called library *must* be used to keep compatibility (in case of hidden dependency without published matching SRPMS) with RHEL.
Ljubomir