Red Hat Bugzilla – Bug 103495
RFE: Build an extra debuggable library subpackage
Last modified: 2007-11-30 17:10:31 EST
Build a new subpackage named XFree86-libs-debug containing an additional
set of libs built for debugging. Need to investigate if it is more
beneficial to do this in addition to the XFree86-libs package, or just
build the main libs with debug info in them always.
That will help make up for the lack of .debuginfo packages, which are next
to impossible to generate for XFree86 while still allowing me to debug
the X server and it's modules. Whenever gdb can debug the X server properly,
I can investigate .debuginfo instead.
Having debuggable libraries available with the shipped OS is
definitely an advantage. There are 2 main ways we could do this.
The first, is to implement what is requested above.
The second method, is to make debuginfo packages just for the
The third method is to split the libraries out into separate
subpackages, which include their own debuginfo packages.
#1 is probably the easiest to implement, and I believe is relatively
easily doable by tweaking host.def during compilation and getting
Imake to spit out an extra set of debuggable libraries, which
could be installed separately from a new subpackage. This is
an X specific debuggable library hack though, and is a bit ugly,
while it is probably the easiest solution to implement and would
nonetheless provide the needed functionality.
#2 is much more difficult to implement since it is complicated
to produce debuginfo subpackages in the XFree86 and xorg-x11
packaging because we can't use rpm's default stripping behaviour.
In order to implement debuginfo for X, we would have to replicate
the rpm scripts which implement debuginfo *inside* the X build
process. That alone isn't complex for one OS release, but since
this changes every OS release, we'd need to implement it separately
for every single OS release we wish to have xorg-x11 buildable
on, which is a total nightmare (I've tried to do this).
#3 is the ultimate solution. By using modularized and autotooled
libraries, they can be built normally and use standard/stock rpm
stripping behaviour. Only the X server and it's modules are
affected negatively by rpm's default stripping behaviour, which
is why there are no .debuginfo rpms for X currently.
The perfect solution (#3) requires that we first are using a
modular build of X, in which some or all of the libraries are
built from their own rpms. While this is a wanted feature, it
is not yet integrated into Fedora Core, and while some of the
libraries are available modular, most of them are canonical
in monolithic form and wouldn't be available outside of the
Imake built monolithic tree for the forseeable future. So
realistically, solution #3 wont be available until at least
X.Org 6.9.0 minimum, perhaps longer.
Solution #2 is a huge mess to even consider attempting, unless
it can be done inside the Imake framework cleanly and submitted
as patches to upstream X.Org, to minimize maintenance headaches.
Solution #1 is the easiest to implement, but the least modern
and clean compared to the niceness of the debuginfo packages.
Nonetheless, I think this is still the best solution for us to
consider for now.
Summary: We should consider doing solution #1 for Fedora Core 3,
or alternatively deferring this issue until Fedora Core 4 development,
at which time we should re-explore the above 3 options and any
other possibilities which might arise.
Flagging bug as FC4Target, setting to ASSIGNED state.
I've investigated this and have concluded that the effort is not worth
the time. Once we have modularized X11R7 in the tree, we'll have
debuginfo packages for free for everything except perhaps the X server
and driver modules, but perhaps even for them using the dlloader.
Adding this feature to the packaging at this point would only benefit
Fedora Core 4, and would require additional conditionalization complications
in the xorg spec file, which seems hardly worth the effort.
Removing from trackers, and setting status to "WONTFIX".