Problem with renamed static constants in .o file

Tue Sep 28 17:54:00 GMT 2004

I encountered a strange linking problem and traced it to what I think
amounts to GCJ arbitrarily changing the name of a Java constant in the
generated object file. I've found a name which lets me duplicate the
problem easily, FOR_OFFICIAL_USE_ONLY. Take the following Java class:
---------------------------
public class MyClass {
 public static final String STATIC_STRING = "STATIC STRING";
 public static final String FOR_OFFICIAL_USE_ONLY = "FOUO";
 public static void main(String[] args)
 {
 System.out.println(STATIC_STRING);
 System.out.println(FOR_OFFICIAL_USE_ONLY);
 }
}
---------------------------
gcjh creates the header file correctly:
---------------------------
// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-
#ifndef __MyClass__
#define __MyClass__
#pragma interface
#include <java/lang/Object.h>
#include <gcj/array.h>
extern "Java"
{
 class MyClass;
}
class MyClass : public ::java::lang::Object
{
public:
 static void main (JArray< ::java::lang::String *> *);
 MyClass ();
 static ::java::lang::String *STATIC_STRING;
 static ::java::lang::String *FOR_OFFICIAL_USE_ONLY;
 static ::java::lang::Class class$;
};
#endif /* __MyClass__ */
---------------------------
However, the following C++ program will not link because it cannot find
the MyClass::FOR_OFFICIAL_USE_ONLY variable:
---------------------------
#include <gcj/cni.h>
#include <java/lang/System.h>
#include <java/io/PrintStream.h>
#include "MyClass.h"
int main(int argc, char* argv[]) {
 JvCreateJavaVM(NULL);
 JvAttachCurrentThread(NULL, NULL);
 java::lang::System::out->println((JvNewStringLatin1("Test.")));
 java::lang::System::out->println(MyClass::STATIC_STRING);
 java::lang::System::out->println(MyClass::FOR_OFFICIAL_USE_ONLY);
}
---------------------------
Now, if I use nm on the generated object file for MyClass, I find the
following line:
00000004 B _ZN7MyClass22FOR_OFFICIAL_U_SE_ONLYE
It seems as if GCJ has placed an underscore after the U in "USE" for
some reason. Is this a GCJ compiler bug? I am using GCJ 3.4.0 on
Fedora Core 2, by the way, via the gcc34 package.