Bug 869578 - Weird symbol _ZGr8_$_dummy in gjc-created object file
Weird symbol _ZGr8_$_dummy in gjc-created object file
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ecj (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jon VanAlten
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-24 06:15 EDT by Pavel Raiskup
Modified: 2015-07-13 00:43 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-16 11:23:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Libtool's testsuite log for java convenience test (4.94 KB, text/plain)
2012-10-24 06:15 EDT, Pavel Raiskup
no flags Details

  None (edit)
Description Pavel Raiskup 2012-10-24 06:15:18 EDT
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 06:30:53 EDT
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 06:43:33 EDT
(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 07:06:49 EDT
(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-29 21:35:43 EDT
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

Note You need to log in before you can comment on or make changes to this bug.