Bug 133898 - incorrect classpath: /usr/share/java/libgcj-3.4.1.jar
incorrect classpath: /usr/share/java/libgcj-3.4.1.jar
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-09-28 07:36 EDT by Neal Becker
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-07 15:04:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
jhbuild log (6.35 KB, application/x-gzip)
2004-10-06 18:13 EDT, Zack Cerza
no flags Details

  None (edit)
Description Neal Becker 2004-09-28 07:36:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
>javac
incorrect classpath: /usr/share/java/libgcj-3.4.1.jar

Version-Release number of selected component (if applicable):
java-1.4.2-gcj-compat-devel-1.4.2.0-1jpp

How reproducible:
Always

Steps to Reproduce:
1.javac
2.
3.
    

Additional info:
Comment 1 Zack Cerza 2004-10-06 17:43:01 EDT
The following workaround fixed the classpath error for me.

# perl -pe 's/3\.4\.1/3\.4\.2/g' -i
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javac

However, my builds are still failing. At least it's a different error now:
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64/crti.o(.init+0x0):
In function `_init':
: multiple definition of `_init'
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64/crti.o(.init+0x0):
first defined here

;)
Comment 2 Thomas Fitzsimmons 2004-10-06 17:56:36 EDT
OK, I'm testing a fix for the classpath problem.

What is the build command you're running when you see this error?  Are
you trying to link something?
Comment 3 Zack Cerza 2004-10-06 18:13:32 EDT
Created attachment 104875 [details]
jhbuild log

This occurred when 'jhbuild bootstrap' tried to build gettext-0.14.1 on x86_64.


Here's the long, long buildlog :)
Comment 4 Thomas Fitzsimmons 2004-10-06 18:23:34 EDT
/bin/sh ./libtool --mode=link g++  -g -O2   -o libasprintf.la -rpath
/opt/gnome2
/lib64  lib-asprintf.lo autosprintf.lo
g++ -shared
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64/crti.o /usr
/lib/gcc/x86_64-redhat-linux/3.4.2/crtbeginS.o  .libs/lib-asprintf.o
.libs/autos
printf.o  -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2
-L/usr/lib/gcc/x86_64-redhat-
linux/3.4.2/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../..
-L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64
-redhat-linux/3.4.2/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../..
/lib64/crtn.o  -o .libs/libasprintf.so.0.0.0

That looks like a libtool problem, likely caused by /usr/lib64 !=
/usr/lib.  What version of libtool does CVS gettext use?  Can you link
a "Hello World" C++ app?

Comment 5 Thomas Fitzsimmons 2004-10-07 15:04:05 EDT
The classpath problem is fixed in the current rawhide release,
java-1.4.2-gcj-compat-1.4.2.0-10jpp.  The linking problem is a
separate issue and should be filed in a separate report.  Closing this
one.

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