On Thu, Jan 27, 2005 at 11:19:12AM -0600, Gary V. Vaughan wrote:
> I am trying to port rpm-4.2 to various other Unixes (AIX, HP/UX, OSF
> etc) using the vendor supplied compilers. The sources for libelf in
> the rpm tree are full of GCCisms (features.h, __attribute__
> decorations, macros using __typeof), so I was wondering what libelf
> is actually used for in rpm?
>
Actually C99'isms, the code is quite conformant.
Libelf is used for 3 things, and they're not necessary on non-linux:
a) for prelinking libraraies, --verify needs to detect a prelinked
library, and run a prelink undo in order to verify the digest.
If you're not prelinking, you won't care, and the code is
conditioned on HAVE_LIBELF_H.
b) internal dependency generation. The traditional find-{requires,provides}
are rather grotty (but useful) scripts that break, like all scripts break,
because, say, /etc/magic changed. Additionally, rpm-4.2 and later has support
for multilib, which identifies files and dependencies as being
elf32 or elf64. There was no way to do pass that information through
the existing find-{requires,provides} API, and, in addition, it was
(and is) a nasty mess of sorts and other tag lookup data and more so
that rpm could guarantee both forward and backward compatibility
of package content with both newer and legacy rpm. So it was easier
(and more reliable) to link an elf lib, and elfutils is the best
library available, even if there are some unusual C99 constructs
that make your non-gcc head hurt.
This can be worked around on non-linux by setting the macro
%_use_internal_dependency_generator 0
and using the traditional find-{provides,requires}.
c) There's one final piece associate with tools/debugedit.c, which
links libdwarf which of course is useless on non-elf. You don't
need debugedit, which means you won't be able to build -debugedit
packages, and you really should not care. If you do care, then
you will need to roll up your sleeves and do the port, which is
rather non-trivial.
If you are building rpm on non-linux, nuke elfutils instantly:
rm -rf elfutils
and perhaps beecrypt as well (easier to build outside of rpm)
rm -rf beecrypt
and probably zlib too
rm -rf zlib
and then avoid the build failure of debugedit.
This is not done withing rpm sources for you, basically because
I do not have access to any platform other than Mac OS X these days,
and so cannot test the configgery.
Nor do I really *want* access, I'm in no position to support
rpm across the entire whore house of uglix. If you do have patches,
I'll be more than happy to attempt to add to rpm, but I cannot
maintain the patch.
> It seems as though rpmdb/legacy.c needs it to support rpm 3.0 era
> packages, which I don't need since any rpms I install will be with
> the rpm-4.2 package I am trying to build right now. Is libelf
> needed for anything else? Can I expect rpm to work properly if
> I get it to compile and link without libelf?
>
rpmdb/legacy.c should not be a problem building rpm afaik. Many
other problems need solve building rpm before you need to worry
about rpmdb/legacy.c.
HTH
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
