Bug 133898 - incorrect classpath: /usr/share/java/libgcj-3.4.1.jar
Summary: incorrect classpath: /usr/share/java/libgcj-3.4.1.jar
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
 
Reported: 2004-09-28 11:36 UTC by Neal Becker
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-07 19:04:05 UTC
Type: ---
Embargoed:


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

Description Neal Becker 2004-09-28 11:36:13 UTC
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 21:43:01 UTC
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 21:56:36 UTC
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 22:13:32 UTC
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 22:23:34 UTC
/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 19:04:05 UTC
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.