I certainly understand the frustration in that I experience it identically
in other areas.
From your other email, I read
> I'm looking for libraries with _MISSING_ SONAME's. The solution there is
> to add DT_SONAME
> with -Wl,soname,YOUR_SONAME
It's been decades, literally, since I handled C linking on a daily basis.
So, assuming that we did locate such missing entries, is this something
that would need to be done at compile/link time or are those switches that
can be applied via a spec file/rpmbuild? Are there existing mechanism for
re-building a compiled .so without access to the source?
On Sun, Jan 6, 2013 at 2:48 PM, Jeffrey Johnson <email@example.com> wrote:
> On Jan 6, 2013, at 3:34 PM, Mykel Alvis wrote:
> > I think it's OK to do this, but I'm going to do so directly to your
> personal email so that I don't display piles of potentially litigious data
> in a public forum.
> Please reply with readelf output publically: the output is not that large
> if you
> grep out only the "SONAME" (i.e. the Provides:) and the "NEEDED" (i.e the
> Requires:) for a couple of libraries and executables.
> There are also specific options to display exactly DT_SONAME/DT_NEEDED
> if you wish to read "man readelf": I deliberately gave you the easier to
> readelf -a ... | grep SONAME
> as something that an average RPM packager faced with a similar problem
> Google search might find useful, comprehensible, and perhaps easier to
> remember. YMMV.
> Most users with RPM problems now use Google search first, you included.
> This leads to a preponderance of problem (but not solution) reports.
> For something like RPM w >15y of serachable information, searching can and
> will find
> just about every answer you want to hear, with many answers that
> appropriate and generally foolish. If one is smart enough, one can
> sometimes find the "best"
> solution. But generally, the deluge of possibile answers and "No time!"
> precludes "best"
> or even "thoughtful".
> Yes I respond to requests out of "good will", formerly out of some
> misplaced sense of duty
> and obligation to assist with information on software I wrote and happen
> to know quite well.
> The specific parts of your problem that have only to do with RPM are the
> metadata in
> *.rpm package headers. The parts of this problem that I cannot help
> directly with are
> what the packages are used for, how the software is to be built, how to
> setup yum repositories,
> and why yum on RHEL (more likely CentOS) is reporting a dependency
> failure. The
> other issues are implicitly related to the (non-)existence of metadata, as
> well as coupled
> into the root causes for your specific issue, and cannot be ignored (or
> solved by RPM).
> 73 de Jeff
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
Received on Sun Jan 6 22:18:51 2013