Bug 869578

Summary: Weird symbol _ZGr8_$_dummy in gjc-created object file
Product: Red Hat Enterprise Linux 7 Reporter: Pavel Raiskup <praiskup>
Component: ecjAssignee: Jon VanAlten <jon.vanalten>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: aph, dbhole, jon.vanalten
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-16 15:23:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Libtool's testsuite log for java convenience test none

Description Pavel Raiskup 2012-10-24 10:15:18 UTC 
Created attachment 632678 [details]
Libtool's testsuite log for java convenience test

gjc utility in RHEL-7.0 seems to create '_ZGr8_$_dummy' read only symbol in
each object file.

Reproducer:

    $ echo "class Test {}" > test.java
    $ gcj -c test.java
    $ nm test.o | grep dummy
    0000000000000000 R _ZGr8_$_dummy

Problem with this behavior occurs when user wants to link together two object
files -> this symbols will conflict then.

This does not happen in Fedora 17, RHEL-6.4, ..

Some info from Google:

    http://stackoverflow.com/questions/2567230/gcj-creates-duplicate-dummy-symbol
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143

And some discussion:

    http://gcc.gnu.org/ml/java-patches/2009-q1/msg00049.html

===
I'm reporting this because building of libtool fails on rhel-7.0 during
running of the upstream testsuite.  See the tests/convenience.at file and the
'Java convenience archives' test inside. (make check-local TESTSUITEFLAGS='37'
-- result is in attachment)
===

Pavel
Comment 1 Jakub Jelinek 2012-10-24 10:30:53 UTC 
As the compiler is the same in between F17 and F18/RHEL7, I bet what changed is ecj.
Comment 2 Pavel Raiskup 2012-10-24 10:43:33 UTC 
(In reply to comment #1)
> As the compiler is the same in between F17 and F18/RHEL7, I bet what changed
> is ecj.

Sorry Jakub, I should file this bug against ecj.  Thanks
Comment 3 Pavel Raiskup 2012-10-24 11:06:49 UTC 
(In reply to comment #2)
> (In reply to comment #1)
> > As the compiler is the same in between F17 and F18/RHEL7, I bet what changed
> > is ecj.
>
> Sorry Jakub, I should file this bug against ecj.  Thanks

Confirmed ... I tested 'gcj' utility with downgraded package 'ecj' to:

  ecj-3.4.2-13.fc17.x86_64

.. on RHEL-7.0 and symptoms disappeared:

  $ cat /etc/redhat-release
  Red Hat Enterprise Linux Workstation release 7.0 Alpha2 (Maipo)
  $ rpm -qv gcc-java
  gcc-java-4.7.2-3.el7.x86_64
  $ rpm -qv ecj
  ecj-3.4.2-13.fc17.x86_64
  $ gcj -c test.java
  $ nm test.o | grep dummy
  # ^^^^ EMPTY ^^^^

Pavel
Comment 4 Jon VanAlten 2012-10-30 01:35:43 UTC 
This comes from some changes to GCCMain from sourceware.org:/cvs/rhug repo which is included in ecj package as entry point for gcc.  The reasons for those changes can still be found in email archives[1].  I'm doing some testing to see if it is OK to patch this out and avoid the symbol in the .o output (I am not incredibly familiar with the details, but following upstream OpenJDK development I am sure I've seen several bugs related to zip files fixed).  Since old ecj package had version of GCCMain that did not introduce this symbol (and nobody in these years has complained), I don't expect a problem.

[1] http://old.nabble.com/-Patch--ecj1-always-fails-with-OpenJDK-runtime.-td22725461.html