Bug 216485 - Test update of Eclipse/libswt3-gtk2 breaks Azureus
Test update of Eclipse/libswt3-gtk2 breaks Azureus
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
6
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-20 13:50 EST by E Mair
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 3.2.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-16 03:31:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description E Mair 2006-11-20 13:50:38 EST
Description of problem:
The latest updates of eclipse and libswt3-gtk2 from updates-testing prevents
Azureus from starting.

Version-Release number of selected component (if applicable):
eclipse-platform-3.2.1-17.fc6.i386.rpm
eclipse-ecj-3.2.1-17.fc6.i386.rpm
eclipse-rcp-3.2.1-17.fc6.i386.rpm
libswt3-gtk2-3.2.1-17.fc6.i386.rpm
azureus-2.5.0.0-8.fc6
Sun JRE 1.5.0-09

How reproducible:
Always

Steps to Reproduce:
1. Install the updated packages mentioned
2. Run azureus
  
Actual results:

$ azureus
/usr/bin/build-classpath: error: Could not find swt-gtk-3.2 Java extension for
this JVM
/usr/bin/build-classpath: error: Some specified jars were not found
Exception in thread "main" java.lang.NoClassDefFoundError:
org/eclipse/swt/widgets/Display
        at org.gudy.azureus2.ui.swt.Main.<init>(Main.java:147)
        at org.gudy.azureus2.ui.swt.Main.main(Main.java:162)
$

Azureus does not start.

Expected results:
Azureus should start

Additional info:
Reverting to eclipse/libswt3-gtk2 3.2.1-4.fc6 will let azureus start again.
Comment 1 Ben Konrath 2006-11-20 13:56:30 EST
Azureus needs to be rebuilt. Andrew said that he would take care of it.
Re-assigning bug to him.
Comment 2 Andrew Overholt 2006-11-20 14:09:13 EST
Yeah, I'm going to rebuild the stuff in Extras but I can't do that until the
update is out as I don't think Extras has an updates-testing equivalent.
Comment 3 John Thacker 2006-11-30 09:10:46 EST
Rebuilding azureus currently doesn't work, BTW, since the default install of
java can't find swt-gtk-3.2 when building azureus either, just like running it.

Moving the swt-gtk-3.2.jar file from /usr/share/java/ to /usr/lib[64]/eclipse is
the cause of that problem.  Judging by the locations of jar files for other
packages, the .jar.so and .jar.db files should be in /usr/lib[64], but the plain
swt-gtk-3.2.jar and swt-gtk-3.2.1.jar files should remain in /usr/share/java, or
at least there should be a link to them in /usr/share/java.  (I suppose that the
search path for java could be changed too, but symbolic links seem easier.)
Comment 4 Andrew Overholt 2006-11-30 09:19:43 EST
(In reply to comment #3)
> Rebuilding azureus currently doesn't work, BTW, since the default install of
> java can't find swt-gtk-3.2 when building azureus either, just like running it.

The jars are arch-specific and cannot be in /usr/share.  It's a simple matter of
rebuilding and changing azureus.script.  I think I committed this to Extras CVS
but didn't build.  I will do so once the update is released.
Comment 5 John Thacker 2006-11-30 18:28:35 EST
> The jars are arch-specific and cannot be in /usr/share.

True, yet for some reason that doesn't seem to stop all the other packages from
putting them there.  But it is more correct, I grant.

> I think I committed this to Extras CVS but didn't build.

Unfortunately, you'll have to change it for bouncycastle 1.34 as well, which was
just updated to 1.34.  Change to /usr/share/java/gcj-endorsed/bcprov-1.34.jar
and all.  (The advantage of /usr/share/java being in the lack of having to
specify the versions to much, even if technically wrong.  Someone should fix it,
I suppose.)
Comment 6 Andrew Overholt 2006-11-30 19:04:15 EST
(In reply to comment #5)
> > The jars are arch-specific and cannot be in /usr/share.
> 
> True, yet for some reason that doesn't seem to stop all the other packages from
> putting them there.  But it is more correct, I grant.

I didn't think other packages had arch-specific jars.  What are you thinking of?

> > I think I committed this to Extras CVS but didn't build.
> 
> Unfortunately, you'll have to change it for bouncycastle 1.34 as well, which was
> just updated to 1.34.  Change to /usr/share/java/gcj-endorsed/bcprov-1.34.jar
> and all.  (The advantage of /usr/share/java being in the lack of having to
> specify the versions to much, even if technically wrong.  Someone should fix it,
> I suppose.)

Can you file that last one against azureus, please?  Thanks.
Comment 7 Ben Konrath 2006-12-03 18:54:44 EST
As Andrew mentioned, the swt jar is arch-specific. This is because the java
source in swt is pre-processed to use ints on 32-bit platforms and longs on
64-bit platfroms. Not to mention that the swt jar includes its JNI libs.

That said, I just re-read the FHS and think there may be a small problem with
what we have. 

From
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA:

"/usr/lib : Libraries for programming and packages
Purpose

/usr/lib includes object files, libraries, and internal binaries that are not  
  intended to be executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an application
uses a subdirectory, all architecture-dependent data exclusively used by the
application must be placed within that subdirectory. [23]"

So what we should really do is move the swt symlinks from /usr/lib/eclipse to
/usr/lib because applications shouldn't be digging in /usr/lib/eclipse. Strictly
speaking, we should also remove the JNI symlinks from /usr/lib because those are
private to swt. However if we did this, applications would have to set the
java.library.path vmarg which may not be desirable. Andrew, do you have any
thoughts here?
Comment 8 Andrew Overholt 2006-12-04 10:06:57 EST
Adding Tom Tromey to tap into his expertise.

(In reply to comment #7)
> "/usr/lib : Libraries for programming and packages
> Purpose
> 
> /usr/lib includes object files, libraries, and internal binaries that are not  
>   intended to be executed directly by users or shell scripts. [22]
> 
> Applications may use a single subdirectory under /usr/lib. If an application
> uses a subdirectory, all architecture-dependent data exclusively used by the
> application must be placed within that subdirectory. [23]"
> 
> So what we should really do is move the swt symlinks from /usr/lib/eclipse to
> /usr/lib because applications shouldn't be digging in /usr/lib/eclipse.

But nothing should be linking against the JNI libraries.  Those are dlopen'd only.

> Strictly speaking, we should also remove the JNI symlinks from /usr/lib
> because those are private to swt.

Yeah, I guess.

> However if we did this, applications would have to set the
> java.library.path vmarg which may not be desirable. Andrew, do you have any
> thoughts here?

I'm pretty sure proprietary JVMs require the setting of java.library.path even
with the stuff in /usr/lib.  I'm not sure it's undesirable but I really don't
know.  Tom?
Comment 9 Russell Harrison 2006-12-05 23:48:37 EST
I picked up the new eclipse jvms this evening from the standard updates repo. 
This bug is now present in the default repos.
Comment 10 Jan-Thomas Czornack 2006-12-06 02:29:21 EST
Is there an easy way to get azureus to start again (without reverting to the old
libswt3-gtk2)?
Comment 11 Andrew Overholt 2006-12-06 08:49:13 EST
I built an updated azureus.  I tried to synchronize the two updates as best as
possible.  Is the new azureus not available yet?
Comment 12 Andrew Overholt 2006-12-06 09:35:17 EST
I asked on fedora-extras-list and the response I got to my question of "When
will the newly-built azureus get pushed out?" was:  "The only delay will be the
delay it takes to mirror the files from an internal server to the public servers."
Comment 13 E Mair 2006-12-06 23:37:53 EST
Got the updates now. However...

azureus-2.5.0.0-9.fc6
eclipse-*-3.2.1-23.fc6
bouncycastle-1.34-1

...just gives this before exiting:

$ azureus
Exception in thread "main" java.lang.NoClassDefFoundError:
org/bouncycastle/jce/spec/ECParameterSpec
        at
com.aelitis.azureus.core.security.impl.CryptoManagerImpl.<init>(CryptoManagerImpl.java:75)
        at
com.aelitis.azureus.core.security.impl.CryptoManagerImpl.getSingleton(CryptoManagerImpl.java:60)
        at
com.aelitis.azureus.core.security.CryptoManagerFactory.getSingleton(CryptoManagerFactory.java:33)
        at
com.aelitis.azureus.core.impl.AzureusCoreImpl.<init>(AzureusCoreImpl.java:155)
        at
com.aelitis.azureus.core.impl.AzureusCoreImpl.create(AzureusCoreImpl.java:92)
        at
com.aelitis.azureus.core.AzureusCoreFactory.create(AzureusCoreFactory.java:46)
        at org.gudy.azureus2.ui.swt.Main.<init>(Main.java:143)
        at org.gudy.azureus2.ui.swt.Main.main(Main.java:162)
Comment 14 Andrew Overholt 2006-12-07 09:59:03 EST
(In reply to comment #13)
> Got the updates now. However...
> 
> azureus-2.5.0.0-9.fc6
> eclipse-*-3.2.1-23.fc6
> bouncycastle-1.34-1
> 
> ...just gives this before exiting:
> 
> $ azureus
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/bouncycastle/jce/spec/ECParameterSpec

Hmm.  Can you file a new bug against azureus for that?  CC fitzsim@redhat.com
when you do as he does bouncycastle.  Thanks.
Comment 15 E Mair 2006-12-07 10:51:31 EST
> Hmm.  Can you file a new bug against azureus for that?  CC fitzsim@redhat.com
> when you do as he does bouncycastle.  Thanks.

Done. Please see bug #218794
Comment 16 Ben Konrath 2007-02-06 14:30:08 EST
Andrew, what's going on with this bug?
Comment 17 Andrew Overholt 2007-02-06 14:32:48 EST
I can't verify ATM (I've got a new gcc RPM which kills old non-BC-compiled
stuff) but I'm pretty sure Azureus is fine in FC6 now.  I don't know about
rawhide, but I'm pretty sure I filed a bug with Anthony to use the new swt JNI
symlinks you put in.

Anthony?

Is azureus broken for anyone else right now?
Comment 18 Andrew Overholt 2007-04-13 10:02:13 EDT
Azureus seems to work in FC6 for me.  I didn't try downloading anything, but
startup worked.  Should we close this bug now?
Comment 19 E Mair 2007-04-14 07:14:43 EDT
Works for me.
Comment 20 Ben Konrath 2007-04-16 03:31:06 EDT
Closing bug as Azureus currently works in FC-6.

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