Daniel Risacher writes: > > I recently started developing with gcj on debian and wanted to use > gdb for debugging, but I've struggled a bit with it. I had actually > composed a lengthy set of questions to ask here on the list, but in > writing the email, I stumbled across the answer, which I now present. > > The problem: I wasn't getting any debugging information (line numbers > or local symbols into the code when I compiled with ant. My javac > task in build.xml looked like this: > > <javac debug="true" verbose="yes" debuglevel="source" > includeJavaRuntime="no" > compiler="gcj" destdir="classes"> > <src path="src" /> > <include name="**/*.java" /> > <compilerarg line=" --main=Main -o Coast" /> > </javac> > > The solution was to change the javac task to this: > > <javac verbose="yes" includeJavaRuntime="no" > compiler="gcj" destdir="classes"> > <src path="src" /> > <include name="**/*.java" /> > <compilerarg line="-g --main=Main -o Coast" /> > </javac> > > Note that the 'debug' and 'debuglevel' properties were removed, and > the '-g' option was added to 'compilerarg' > > I hope this helps someone else avoid the hand-wringing and > teeth-gnashing I went through.
I've come across a few RPMS with missing debuginfo and wasted a great deal of time trying to rebuild to get the debuginfo. The problem seems to be that some ant scripts force debugging to be off or perhaps inherited from a property that no-one remembered to set. This is compounded by the fact that some ant scripts unzip source archives and then call ant recursively to build them: in such a case it's very hard to patch build.xml to force debugging=true. This patch for ecj forces debuginfo always to be generated while rebuilding an RPM, no matter what ant thinks. I realize it's something of a kludge, but it's better than the current situation. When compiling C/C++/etc, RPM passes "-g" in RPM_OPT_FLAGS. An alternative to this patch might be to scan RPM_OPT_FLAGS for "-g" and only turn on debugging if it's present. However, I doubt that in practice it'd make any difference. Something similar would work for Debian. I know of no circumstances in which we ever wish to ship packages that don't have debuginfo. Andrew. --- eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java.orig 2006-01-19 17:53:49.000000000 +0000 +++ eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java 2006-01-19 18:06:32.000000000 +0000 @@ -2405,6 +2405,29 @@ this.times = new long[this.repetitions]; this.timesCounter = 0; } + + { + // If we're building an RPM, force full debugging info to + // be generated, no matter what options have been passed + // by Ant. This is something of a kludge, but it is far + // better than the alternative, which is having class + // files with debug info mysteriously missing. + + String RpmPackageName = System.getenv("RPM_PACKAGE_NAME"); + String RpmArch = System.getenv("RPM_ARCH"); + String RpmBuildRoot = System.getenv("RPM_BUILD_ROOT"); + if (RpmPackageName != null && RpmArch != null && RpmBuildRoot != null) { + this.options.put( + CompilerOptions.OPTION_LocalVariableAttribute, + CompilerOptions.GENERATE); + this.options.put( + CompilerOptions.OPTION_LineNumberAttribute, + CompilerOptions.GENERATE); + this.options.put( + CompilerOptions.OPTION_SourceFileAttribute, + CompilerOptions.GENERATE); + } + } } private void addNewEntry(final int InsideClasspath, final int InsideSourcepath, ArrayList bootclasspaths, ArrayList classpaths,ArrayList sourcepathClasspaths, String currentClasspathName, ArrayList currentRuleSpecs, int mode, String customEncoding) { -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]