Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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-symbolhttp://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
(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
(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
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