Symbol compression?, linking problems.

Mon May 14 16:35:00 GMT 2001

Okay, yes I'm fairly certain now. g++ and gcj are compressing symbols 
differently. I even threw at them the exact same "largest symbol" thinking 
that would be a work around, but they are just fundamentally "working 
differently". g++ gave me for the same function: (output from nm)
00000040 T 
_ZN3gnu3awt7picogui12PguiMenuPeer7addItemEPN4java3awt4peer12MenuItemPeerEPNS4_12MenuShortcutE
gcj gave me:
 U 
_ZN3gnu3awt7picogui12PguiMenuPeer7addItemEPNS0_4peer12MenuItemPeerEPNS0_12MenuShortcutE
Gcj seems to take a more global position and apply it's "shortening" more 
broadly at the namespace level. Like above, g++ did calculate a "shortening" 
for java.awt, but it didn't apply it to java.awt.peer.MenuItemPeer, where as 
gcj picked the same package to shorten, but applied it evenly. (And 
strangely enough, with different substitutions, but I think that is because 
g++ only shortens what exists within it's scope of the file, rather than the 
scope of the namespace..., which is really odd and wouldn't work to well if 
you had multiple files for defining the same class, which is *exactly* the 
situation we run into with gcj)
Anyway..., are gcj and g++ going to get on the same page? Or have I 
misdiagnosed? Here's the relavent function/class excerpt:
package gnu.awt.picogui;
import java.awt.*;
import java.awt.peer.MenuPeer;
import java.awt.peer.MenuItemPeer;
public class PguiMenuPeer extends PguiMenuItemPeer
 implements MenuPeer
{
 public native void addItem(java.awt.peer.MenuItemPeer item, MenuShortcut 
ms);
 ....
}
Should this be fixed, or worked around? And does anyone have any suggestions 
for how we could approach the issue with the g++ team? (To avoid..., your 
symbol mangling is broken..., no yours! ...:)
Thanks,
Shane Nay.