Red Hat Bugzilla – Bug 153247
eclipse-debuginfo is missing source code and debuginfo
Last modified: 2008-04-04 20:57:50 EDT
Description of problem:
The eclipse-debuginfo package is missing the source code.
Version-Release number of selected component (if applicable):
Paul said he would comment on this when he had a chance. The source for
debuginfo is apparently being lost in the .java -> .jar -> .jar.so compilations.
I believe this is due to the absence of -g in the .jar -> .jar.so compilation.
I will test a .spec patch tommorow. Eclipse takes several hours to build on my
box - we'll see if adding $RPM_BUILD_OPTS to the gcj command line fixes it.
By the way, not only does eclipse-debuginfo not contain any source code, it
appears to be missing a lot of debugging info. Updated summary.
Created attachment 114257 [details]
The -g flag has already been added in CVS, which is half the problem solved.
The attached patch completes the fix. There are a lot of spurious cpio errors
when rpmbuild builds the -debuginfo package, which are due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20735, but it works.
(A similar strategy should also work for ant, which also doesn't have any
source code in its debuginfo package.)
Thanks for the patch. I agree with you that it's a hack :)
Paul, can you think of a better way to do this? There are a few options:
1. change gdb to read from zipped sources (which are in eclipse*-devel already)
(and set that up ie. path resolution)
2. change Eclipse to read source from debuginfo files (lame from and Eclipse
3. ram the source into the debuginfo packages a la Robin's patch (duplicates the
code but if people install debuginfo I guess they know what they're getting into
3. is probably the best option ATM, but it's very package-specific and we're
going to need to do it for all java packages in FC.
Are there other options we're missing?
There is another problem now. The libswt debuginfo is not being included in the
I'd hazard a guess that's because libswt is in the wrong place. It should not be
under /usr/share because it's a native lib. Instead, it should be somewhere
under /usr/lib and symlinked from the location eclipse expects to find it at.
(In reply to comment #6)
> I'd hazard a guess that's because libswt is in the wrong place. It should not be
> under /usr/share because it's a native lib. Instead, it should be somewhere
> under /usr/lib and symlinked from the location eclipse expects to find it at.
The JNI .sos for libswt are in /usr/lib and symlinked.
*** Bug 217004 has been marked as a duplicate of this bug. ***
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
I don't have time to work on this and seeing as people haven't run into a
problem with this in a long time, it's probably safe to close. We can always
thanks for your update