Bug 207016 - Eclipse packages are not multilib
Eclipse packages are not multilib
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
6
ppc64 Linux
high Severity urgent
: ---
: ---
Assigned To: Ben Konrath
:
Depends On:
Blocks: 212878 212879
  Show dependency treegraph
 
Reported: 2006-09-18 15:31 EDT by IBM Bug Proxy
Modified: 2013-01-09 23:04 EST (History)
7 users (show)

See Also:
Fixed In Version: 3.2.2-1.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-23 11:49:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
install.log (49.21 KB, text/plain)
2006-10-06 14:31 EDT, Andrew Overholt
no flags Details
glibc memory corruption output from gedit (ppc) (29.25 KB, text/plain)
2006-10-18 00:39 EDT, Ben Konrath
no flags Details
log.eclipsefc6 (2.21 KB, text/plain)
2006-12-13 15:01 EST, IBM Bug Proxy
no flags Details
eclipse-test.txt (1.53 KB, text/plain)
2006-12-14 08:16 EST, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 27311 None None None Never

  None (edit)
Description IBM Bug Proxy 2006-09-18 15:31:23 EDT
LTC Owner is: ameet@us.ibm.com
LTC Originator is: robbiew@us.ibm.com


Problem description: Eclipse is failing to start in FC6-test3


If this is a customer issue, please indicate the impact to the customer:
IBM intends on releasing an update to the Cell SDK to customers at the end of
this year.  The SDK is targeted for use on Fedora Core 6.  Part of the update
includes an IDE that uses Eclipse CDT.

Hardware Environment
    Machine type (p650, x235, SF2, etc.): QS20 (cell-blade)
    Cpu type (Power4, Power5, IA-64, etc.): CBE
    

Is this reproducible? Yes
    If so, how long does it (did it) take to reproduce it? seconds
    Describe the steps: start 'eclipse' from the command line.

Is the system (not just the application) hung? no
    If so, describe how you determined this:

Did the system produce an OOPS message on the console? no
    If so, copy it here:

Is the system sitting in a debugger right now? no
    If so, how long may it stay there?


Additional information: 
The following information was placed in the 'workplace/.metadata/.log':
-----------------------------------------------------------------------
!SESSION 2006-09-15 10:31:22.697 -----------------------------------------------
eclipse.buildId=M20060629-1905
java.fullversion=GNU libgcj 4.1.1 20060828 (Red Hat 4.1.1-20)
BootLoader constants: OS=linux, ARCH=ppc, WS=gtk, NL=en_US
Command-line arguments:  -os linux -ws gtk -arch ppc

!ENTRY org.eclipse.osgi 2 1 2006-09-15 10:31:45.770
!MESSAGE NLS missing message: fileInitializer_missingFileName in:
org.eclipse.core.internal.runtime.messages

!ENTRY org.eclipse.osgi 4 0 2006-09-15 10:31:48.103
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError:
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/68/1/.cp/libswt-pi-gtk-3232.so:
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/68/1/.cp/libswt-pi-gtk-3232.so:
wrong ELF class: ELFCLASS32
   at java.lang.Runtime._load(libgcj.so.7rh)
   at java.lang.Runtime.loadLibrary(libgcj.so.7rh)
   at java.lang.System.loadLibrary(libgcj.so.7rh)
   at org.eclipse.swt.internal.Library.loadLibrary(Library.java:123)
   at org.eclipse.swt.internal.gtk.OS.<clinit>(OS.java:22)
   at java.lang.Class.initializeClass(libgcj.so.7rh)
   at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
   at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
   at org.eclipse.swt.widgets.Display.<clinit>(Display.java:126)
   at java.lang.Class.initializeClass(libgcj.so.7rh)
   at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:433)
   at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
   at
org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:122)
   at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:75)
   at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
   at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
   at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
   at java.lang.reflect.Method.invoke(libgcj.so.7rh)
   at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
   at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
   at org.eclipse.core.launcher.Main.run(Main.java:977)
   at org.eclipse.core.launcher.Main.main(Main.java:952)
Comment 1 Ben Konrath 2006-09-18 17:37:02 EDT
What architecture are you running on?
Comment 2 Andrew Overholt 2006-09-18 17:41:07 EDT
(In reply to comment #0)
>     Cpu type (Power4, Power5, IA-64, etc.): CBE

What is CBE?

> Command-line arguments:  -os linux -ws gtk -arch ppc

This is ppc32 AFAIK.

> java.lang.UnsatisfiedLinkError:
>
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/68/1/.cp/libswt-pi-gtk-3232.so:
>
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/68/1/.cp/libswt-pi-gtk-3232.so:
> wrong ELF class: ELFCLASS32

This makes me think that CBE is 64-bit and the 32-bit ppc is being used.
Comment 3 IBM Bug Proxy 2006-09-18 18:01:01 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-09-18 17:57 EDT -------
Architecture is Cell Broadband Engine, which for the purpose of this bug, can be
equated to 64bit PowerPC.  One additional bit of information is that running
'eclipse' from the command line of a similar machine with FC5 installed works. 
Comment 4 Ben Konrath 2006-09-18 18:25:37 EDT
Are you using the ppc or the ppc64 packages? Note that Eclipse doesn't
officially support ppc64 for Eclipse 3.2. We hacked support into our build but
it remains largely untested. 
Comment 5 IBM Bug Proxy 2006-09-19 10:46:05 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-09-19 10:42 EDT -------
We're using what ever the default is for ppc64.  All we do is type 'eclipse' on
the command line and it fails.  Did something change in the eclipse or java
packages between fc5 and fc6-test3 that could cause this? 
Comment 6 IBM Bug Proxy 2006-09-19 15:36:42 EDT
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjashfor@us.ibm.com




------- Additional Comments From cjashfor@us.ibm.com  2006-09-19 15:33 EDT -------
I ran into this problem too.  Maynard Johnson suggested that Eclipse relies on
the IBM JVM and that it doesn't work with GNU Java (yet?).

The IBM JRE was not in the ISO, so I downloaded version 1.4.2. off of the web,
and Eclipse now works better... I get the dialog box that asks me to choose a
workspace, but after I select one, it soon crashes after that.

I will file a separate bugzilla on this. 
Comment 7 Ben Konrath 2006-09-20 16:15:21 EDT
(In reply to comment #5)
> Did something change in the eclipse or java packages between fc5 and 
> fc6-test3 that could cause this? 

Yes, Eclipse was updated from 3.1.2 to 3.2.0 which doesn't officially support
ppc64 (see comment # 4). 

Can you send me the output of this command so that I can verify that you're
using the ppc64 packages:

rpm -qi eclipse-platform | grep "Build Host:"

Comment 8 Ben Konrath 2006-09-20 16:22:37 EDT
(In reply to comment #6)
> I ran into this problem too.  Maynard Johnson suggested that Eclipse relies on
> the IBM JVM and that it doesn't work with GNU Java (yet?).

Eclipse does not rely on the IBM JVM, it works with JVMs from Sun, BEA and GNU
(to name a few). I use Eclipse with GCJ regularly. 

> The IBM JRE was not in the ISO, so I downloaded version 1.4.2. off of the web,
> and Eclipse now works better... I get the dialog box that asks me to choose a
> workspace, but after I select one, it soon crashes after that.

The IBM JRE is proprietary software therefore it cannot be shipped with Fedora.
Please see rh bug # 175547 regarding the 'dialog box prompting for workspace' issue.
Comment 9 IBM Bug Proxy 2006-09-26 09:01:47 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-09-26 08:59 EDT -------
# rpm -qi eclipse-platform | grep "Build Host:"
Install Date: Thu 14 Sep 2006 06:56:18 PM CDT      Build Host:
js20-bc2-9.build.redhat.com 
Comment 10 IBM Bug Proxy 2006-09-26 10:11:18 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-09-26 10:06 EDT -------
For what it's worth, here are the steps that we performed to get Eclipse running
on FC6 for ppc64:

	- Install Eclipse 3.2 and Eclipse CDT 3.1 (both from Eclipse's website) :
		eclipse-SDK-3.2-linux-gtk-ppc
		org.eclipse.cdt-3.1.0-linux.ppc
	- Appended the following line to the eclipse.ini file (inside Eclipse's install
dir)
		-Dosgi.locking=none
	- Install IBM Java 5 ppc :
		ibm-java2-ppc-sdk-5.0-2.0.ppc
	- Disabled SELinux 
Comment 11 Ben Konrath 2006-09-28 13:26:29 EDT
(In reply to comment #9)
> # rpm -qi eclipse-platform | grep "Build Host:"
> Install Date: Thu 14 Sep 2006 06:56:18 PM CDT      Build Host:
> js20-bc2-9.build.redhat.com 

Ok, so you are using the standard ppc64 packages.
Comment 12 Andrew Overholt 2006-10-05 16:06:36 EDT
(In reply to comment #11)
> Ok, so you are using the standard ppc64 packages.

Then why is he getting:

/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/68/1/.cp/libswt-pi-gtk-3232.so:
wrong ELF class: ELFCLASS32
Comment 13 IBM Bug Proxy 2006-10-06 10:20:51 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-06 10:17 EDT -------
Is there something else you need me to run?  Or logfile copied?  We need Eclipse
working in Fedora Core 6 and are willing to help in anyway. 
Comment 14 Andrew Overholt 2006-10-06 13:24:54 EDT
I've sort of tracked this down now that our local G5 is back from the grave.  It
appears that there is some sort of bug in the libgcj packaging such that a
32-bit /usr/bin/gcc exists but a 64-bit /usr/bin/gij is there; both in the
supposedly 32-bit ppc package.  This makes all sorts of weirdness happen with a
32-bit java-1.4.2-gcj-compat but a 64-bit java-1.4.2-gcj-compat-devel.  So the
32-bit libswt RPM is installed (theoretically correct) but the 64-bit gij (which
I think is erroneously in the 32-bit libgcj RPM) can't load it.  Playing tricks
with the RPMs and yum doesn't yield any working results for me due to this
seemingly bi-arch libgcj RPM.

Jakub:  do you have any idea as to what is going on here?  Is this actually a bug?
Comment 15 Andrew Overholt 2006-10-06 14:18:33 EDT
Sorry, the 64-bit /usr/bin/gij is present but RPM thinks the 64-bit RPM is
installed.  Any idea what could cause that?  My knowledge of multi-lib is
limited to the pain it's caused me.

FWIW, frysk was installed which is only ppc64 AFAIK.
Comment 16 Andrew Overholt 2006-10-06 14:31:04 EDT
Created attachment 137939 [details]
install.log

I've attached install.log.  This was a clean install of 2006-10-05 rawhide on a
Mac G5.  You can see that libgcj.ppc is installed and then libgcj.ppc64 is
installed (presumably for frysk ... I guess that's in the default "Developer
Tools" group?).

After installation, a 'yum install eclipse-sdk' was performed which happily
installed the 32-bit (ppc) libswt3-gtk2.  This has 32-bit JNI .sos which don't
run because the 64-bit /usr/bin/gij (aka /usr/bin/java) from libgcj.ppc64 is
present.

Anyone know what went wrong here?  Where's the bug?
Comment 17 Andrew Overholt 2006-10-06 14:33:43 EDT
Jesse, Bill, Jeremy:  any idea what happened here?  Should this be an FC6
blocker?  Default install + simple yum operation with no errors = borked menu
entry for Eclipse.
Comment 18 Jakub Jelinek 2006-10-06 14:39:52 EDT
If libswt3-gtk2 is only available as ppc.rpm and not ppc64.rpm, then that would
be libswt3-gtk2 bug.
libgcj is available as both ppc.rpm and ppc64.rpm and /usr/bin/gij is in both,
when both are installed rpm preferencing (which is broken on ppc, because it
prefers always 64-bit, while on ppc it would be desirable to prefer 32-bit)
determines which type of binaries wins.
Comment 19 Andrew Overholt 2006-10-06 14:43:24 EDT
(In reply to comment #18)
> If libswt3-gtk2 is only available as ppc.rpm and not ppc64.rpm, then that would
> be libswt3-gtk2 bug.

Upstream (eclipse.org) doesn't ship ppc64 binaries but we hack the build to do
so.  Both RPMs are available.

> libgcj is available as both ppc.rpm and ppc64.rpm and /usr/bin/gij is in both,
> when both are installed rpm preferencing (which is broken on ppc, because it
> prefers always 64-bit, while on ppc it would be desirable to prefer 32-bit)
> determines which type of binaries wins.

So does this explain the problem?  From my reading, I don't think so.
Comment 20 Jakub Jelinek 2006-10-06 16:10:57 EDT
Perhaps you are building them as ppc64.rpm also, but they aren't in the ppc
composes.  That's something you'd need to contact the rel-eng folks about,
with a list of packages which need to be multilibbed.
I guess libswt3-gtk2 would be one of those, but you should probably first
download the ppc64.rpm's by hand from ppc64 development tree and test them.
E.g. if eclipse attempts to load
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/17/1/.cp/libswt-glx-gtk-3235.so
unconditionally, without taking the gij arch into account, then what would
that symlink point to?
For most libraries the dynamic linker and/or the apps themselves take care of
loading the right library:
1) either the libraries are in standard search paths (like /usr/lib resp.
/usr/lib64) and are loaded by SONAME or basename
2) the app is using absolute filename, but uses $LIB in filename, as in dlopen
("/foo/bar/$LIB/libfoo.so.25", RTLD_*) in the filename and
the library is in /foo/bar/lib/libfoo.so.25 (32-bit) and
/foo/bar/lib64/libfoo.so.25 (64-bit)
3) for Java libraries there is the classmap.db database and libgcj automatically
chooses the right database and loads library filenames from there
Comment 21 Andrew Overholt 2006-10-06 16:41:36 EDT
(In reply to comment #20)
> Perhaps you are building them as ppc64.rpm also

We are building for every architecture.

> E.g. if eclipse attempts to load
>
/usr/share/eclipse/configuration/org.eclipse.osgi/bundles/17/1/.cp/libswt-glx-gtk-3235.so
> unconditionally, without taking the gij arch into account, then what would
> that symlink point to?

That symlink points to the .so in /usr/lib/eclipse.  We just munge the paths to
match LSB conventions.

Eclipse will attempt to load whatever .so is present on the system as we build
the java code and the JNI code that match.  However, it does this using gij
which will fail if gij's arch and that of the .sos doesn't match.

Is there something that should be done in eclipse.spec to take care of this?  I
can't think of anything since we just Require: java which is provided by
java-1.4.2-gcj-compat which in turn requires gcc-java.
Comment 30 IBM Bug Proxy 2006-10-13 12:00:52 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-13 11:58 EDT -------
Should we re-test for this in FC6-pre? 
Comment 31 Andrew Overholt 2006-10-13 12:06:58 EDT
(In reply to comment #30)
> ----- Additional Comments From robbiew@us.ibm.com  2006-10-13 11:58 EDT -------
> Should we re-test for this in FC6-pre? 

No, it'll still be broken.  We're investigating where the problem lies.  Sorry I
don't have an answer for you yet.
Comment 35 Andrew Overholt 2006-10-17 10:23:01 EDT
(In reply to comment #34)
> It doesn't matter whether the X server works on th ppc{,64} box.  Eclipse is
> only an X client, and it doesn't need the server to be running locally.  Please
> try running ppc Eclipse from a remote X server.

Sorry, I should have been more clear.  I can't get the machine to boot into
runlevel 5.  I can't start X locally.  I also can't run remote gtk apps
remotely.  I can, however, run X apps like xclock remotely.  I'm doing a yum
update now.
Comment 36 IBM Bug Proxy 2006-10-17 15:40:57 EDT
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |agodwin@us.ibm.com




------- Additional Comments From agodwin@us.ibm.com  2006-10-17 15:37 EDT -------
adding myself to CC: list - need this fix for SDK2.0 IVT testing 
Comment 37 Andrew Overholt 2006-10-17 16:17:12 EDT
Let me summarize what I think is the current situation.  Please correct anything
that I say that's wrong.

ppc installation on a 64-bit box results in *both* libgcj packages (ppc and
ppc64) getting installed with the 64-bit one later.  This makes /usr/bin/gij
64-bit which makes eclipse not work.

Can we somehow make the ordering of multilib packages depend upon the
"preferred" word size for the machine?  ie. on ppc if 32-bit is indeed
preferred, can we make the 64-bit libgcj (or whatever multilib package) get
installed before the 32-bit one?

Or should libgcj be fixed to have /usr/bin/gij always be the preferred version
(32-bit or 64-bit)?
Comment 38 Bill Nottingham 2006-10-17 16:23:38 EDT
I don't think we can reliably make that change now, no. For example, you'd
get a compiler that can't compile 64-bit...
Comment 39 Jakub Jelinek 2006-10-17 16:29:37 EDT
gcc is a bad example, ppc.rpm gcc can compile 64-bit, so do ppc.rpm binutils
(we actually ship only the 32-bit ones).
But gdb, maybe strace/ltrace/frysk are different.
Comment 40 Ben Konrath 2006-10-18 00:39:06 EDT
Created attachment 138748 [details]
glibc memory corruption output from gedit (ppc)

As a test, I installed the ppc64 eclipse packages and I did not get the "wrong
ELF class: ELFCLASS32" error. I saw the workbench shell for a quick second, but
it seg faulted at that point. I looked into this seg fault a bit and noticed
that it was seg faulting in libcairo. When I installed the debuginfo package
for libcairo and ran it with gdb, I noticed that the seg fault happened very
shortly after a call to malloc. I didn't do an analysis past this point because
I also noticed that when I ran gedit (32 bit), I got a memory corruption error
message from glibc and I assumed that these were related.

The entire output of the memory corruption message is attached. Let me know if
you'd like a new bug report for this. For the Red Hat folks on this bug, feel
free to login to tofu.toronto to check things out for yourself -- the ppc64
eclipse packages are currently installed.

One thing I noticed when I reverted back to using the ppc eclipse packages was
that eclipse seg faulted when it tried to display the error dialog which is
implemented using gtk. I suppose this is not surprising since no gtk apps are
working right now.

When this gtk problem is fixed, I will re-test the ppc64 eclipse packages. If
they work, will this solve the problem? Is there a way to get the ppc64 eclipse
packages in the collinst without having the pcc packages there?
Comment 42 Ben Konrath 2006-10-18 17:55:49 EDT
I found a work-around for the problem I was having with gtk apps seg faulting
and the ppc64 eclipse packages work fine. So why are the ppc64 packages not
installed on a 'yum install eclipse-sdk'?
Comment 43 Jesse Keating 2006-10-18 18:00:24 EDT
most likely because eclipse-sdk isn't considered multilib (as I'm assuming there
is no eclipse-sdk-devel package)
Comment 44 Andrew Overholt 2006-10-18 18:04:10 EDT
Both libgcj packages are installed because they're both in the yum repo.
eclipse-sdk isn't multilib so only one is present.

How can libgcj provide /usr/bin/gij (among other /usr/bin/ stuff) and be multilib?  Don't the 32-bit and 64-bit versions of /usr/bin/gij (and others) conflict?
Comment 45 Jesse Keating 2006-10-18 19:01:45 EDT
The binaries from the "preferred" arch are whats used.  So for x86_64, the
x86_64 binaries are used rather than the i386 one, when the file is the same. 
The libraries are seperated out into /usr/lib and /usr/lib64 so those can be
seperate.

This works well usually, but not always in the case of interpreters, like say
python.
Comment 46 Thomas Fitzsimmons 2006-10-18 21:07:29 EDT
(In reply to comment #45)
> The binaries from the "preferred" arch are whats used.  So for x86_64, the
> x86_64 binaries are used rather than the i386 one, when the file is the same.

OK.  What is the "preferred" arch on a ppc64 system?
Comment 47 Jesse Keating 2006-10-18 23:07:13 EDT
ppc64 because we can't really do 'ppc32 for these packages, and ppc64 for those
packages'.  So if both ppc32  and ppc64 packages are installed, the ppc64
binaries will be preferred.
Comment 48 Thomas Fitzsimmons 2006-10-18 23:21:19 EDT
In that case, for a ppc64 system, the ppc64 eclipse packages need to be in the
repository/on the installation CD and pulled by default by yum/installed by
default by anaconda.  In other words, if ppc64 packages are preferred (meaning
that the 64-bit /usr/bin/gij is preferred), then having only the 32-bit JNI
packages available is not going to work.  So I think this is a problem with
distill and/or comps.xml and/or the repository setup.

Is the 64-bit libgcj also preferred by yum/anaconda/rpm when installed as the
dependency of a package simply requiring "libgcj"?  If so, then having the ppc64
eclipse packages available in all places will mean that the default
configuration always works.
Comment 49 Jesse Keating 2006-10-18 23:32:03 EDT
Well, there is a difference between what rpm preferrs and what the end user
would prefer.  ppc64 packages are most often SLOWER than the ppc32 package,
except in few cases.  So, while I could make eclipse packages ppc64, they may in
fact perform worse than if they were just ppc32.

yum, which is the basis of anaconda package installation, will instally ALL
packages matching a name across the arches.  So if 'foo' is avail on ppc and
ppc64, a request to install foo will install both (and their deps).
Comment 50 Thomas Fitzsimmons 2006-10-18 23:43:32 EDT
OK, then I think we should make the eclipse packages ppc64, along with any other
JNI-using Java packages.  Having the default configuration working but less
performant than the pure 32-bit case is better than having the default
configuration broken.
Comment 51 Ben Konrath 2006-10-19 00:42:57 EDT
Just to be explicit here, eclipse is currently not multilib compatible so yum
won't be able to install both the ppc and ppc64 packages and prefer the 64-bit
/usr/bin/eclipse and associated 64-bit JNI libraries. Is there a way to make
*only* the ppc64 packages available when the 64-bit /usr/bin/gij is installed 
and *only* the ppc packages available when the 32-bit /usr/bin/gij is installed?
Or will eclipse need to be multilib compatible for this to work?
Comment 52 Jesse Keating 2006-10-19 08:47:26 EDT
Hrm, thats not easy / doable at all :/  The problem is that 64bit /usr/bin/gij
is installed right?  What if we makde gij not multilib, so that only the ppc32
gij was available?  Then the existing eclipse ppc32 would work.  What would that
break?
Comment 53 Andrew Haley 2006-10-19 10:56:10 EDT
It would break frysk.  Please, supply 64-bit Eclipse and be done with it.
Comment 54 Jesse Keating 2006-10-19 11:01:55 EDT
Its too late for FC6.  The change will have to be made for RHEL5 though.  You're
sure that having eclipse.ppc and eclipse.ppc64 won't break anything?  What all
packages of eclipse should be this way?  eclipse* ?

I'm reassigning this to a RHEL5 issue.
Comment 55 Andrew Overholt 2006-10-19 11:10:37 EDT
(In reply to comment #53)
> It would break frysk.  Please, supply 64-bit Eclipse and be done with it.

There *is* a ppc64 Eclipse SDK.  It and the 32-bit eclipse packages are *not*
parallel installable.
Comment 56 Andrew Haley 2006-10-19 11:40:51 EDT
> There *is* a ppc64 Eclipse SDK.  It and the 32-bit eclipse packages are *not*
> parallel installable.

Right, so this is no longer a technical problem at all.  It's a matter of
policy: if you have a 64-bit gij installed, you must install a 64-bit Eclipse.

We could provided a simple program (or perhaps a %post script) that alerts the
user if an incompatible combination has been installed.
Comment 57 Jesse Keating 2006-10-19 11:43:19 EDT
Awesome.  So if I make eclipse multilib, it will have conflicts.  If I don't, it
won't run.  So, we're kind of stuck here guys...
Comment 58 Jesse Keating 2006-10-19 11:45:53 EDT
(In reply to comment #56)
> > There *is* a ppc64 Eclipse SDK.  It and the 32-bit eclipse packages are *not*
> > parallel installable.
> 
> Right, so this is no longer a technical problem at all.  It's a matter of
> policy: if you have a 64-bit gij installed, you must install a 64-bit Eclipse.
> 
> We could provided a simple program (or perhaps a %post script) that alerts the
> user if an incompatible combination has been installed.
> 

%post echos do not work.  They are rarely if ever seen, and often they're too late.

Rpm also does not let you do something like Conflicts: foo.ppc  as it doesn't
understand the ".ppc" stuff yet.  This is really a severe problem and the only
possible solution I see is fixing eclipse to not have multilib conflicts.
Comment 59 Andrew Overholt 2006-10-19 12:07:47 EDT
Tom Fitzsimmons and I just discussed this and have come up with a proposed solution:

1. Ben and I will make our Eclipse packages multilib.  This will involve
diverging from upstream as we will have to make the OSGi runtime look in two
places for bundles:  /usr/share/eclipse and %{libdir}/eclipse.  We will move the
arch-specific bundles (jars) to %{libdir}/eclipse.

2. Once 1. is complete, we will re-request that the 64-bit Eclipse packages be
put into both the ppc and ppc64 yum repos/ISO images/whatever.

In the meantime, can the IBM guys who originally reported this please try
removing the eclipse RPMs (the ppc ones) from their system and try installing
the ppc64 ones?  Something like this:

for f in eclipse-{ecj,{platform,jdt,pde}{,-sdk}} libswt3-gtk2; do \
wget \
http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/Fedora/RPMS/$f-3.2.1-4.fc6.ppc64.rpm
done
rpm -e --nodeps `rpm -qa | egrep "eclipse|libswt3"`
rpm -Uvh *-3.2.1-4.ppc64.rpm
Comment 60 IBM Bug Proxy 2006-10-19 12:31:18 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-19 12:29 EDT -------
doing this now...will update once complete 
Comment 61 Ben Konrath 2006-10-19 12:32:00 EDT
(In reply to comment #59)
> In the meantime, can the IBM guys who originally reported this please try
> removing the eclipse RPMs (the ppc ones) from their system and try installing
> the ppc64 ones?  Something like this:

You will also need to install mesa-libGLU-6.5.1-7.fc6.ppc64.
Comment 62 Ben Konrath 2006-10-19 12:44:00 EDT
A couple of points here:

* It seems to me that something is wrong with the way that multilib is
implemented if applications themselves need to be multilib compatible. For
Eclipse this may turn out to be a significant development effort and it will
certainly involve us diverging from upstream (potentially in a major way). But
if this is the only solution, then I'll get to work on it.

* As Tom Fitzsimmons pointed out, this issue affects all java packages that have
JNI libraries. Someone will need to make sure that all java packages with JNI
libraries are multilib compatible. 
Comment 63 Jesse Keating 2006-10-19 12:52:46 EDT
(In reply to comment #62)
> A couple of points here:
> 
> * It seems to me that something is wrong with the way that multilib is
> implemented if applications themselves need to be multilib compatible. For
> Eclipse this may turn out to be a significant development effort and it will
> certainly involve us diverging from upstream (potentially in a major way). But
> if this is the only solution, then I'll get to work on it.
> 
> * As Tom Fitzsimmons pointed out, this issue affects all java packages that have
> JNI libraries. Someone will need to make sure that all java packages with JNI
> libraries are multilib compatible. 

Yes, some applications were created with zero thought to multilib.  Which is
somewhat fair, multilib is still something of a new idea.  It also finds a LOT
of problems with how applications/packages are put together, such as putting
arch specific code in /usr/share or hardcoding /usr/lib or silly things like
that.  And if more java packages are hurt, thats too bad, they shouldn't have
been doing silly things.
Comment 64 IBM Bug Proxy 2006-10-19 13:26:00 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-19 13:21 EDT -------
Replacing the packages worked!  The GUI comes up without a hitch when I type
'eclipse'.  However, I had to replace/update more than just libswt3-gtk3 and
eclipse.  I also had to update/install, as prereqs, the following ppc64 RPMs:
 mesa-libGLU
 java-1.4.2-gcj-compat
 java-1.4.2-gcj-compat-javadoc

To be "safe" I installed all the ppc64 eclipse related RPMs:
  eclipse-bugzilla-0.2.4-3.fc6.ppc64.rpm
  eclipse-ecj-3.2.1-4.fc6.ppc64.rpm
  eclipse-jdt-3.2.1-4.fc6.ppc64.rpm
  eclipse-jdt-sdk-3.2.1-4.fc6.ppc64.rpm
  eclipse-pde-3.2.1-4.fc6.ppc64.rpm
  eclipse-pde-runtime-3.2.1-4.fc6.ppc64.rpm
  eclipse-pde-sdk-3.2.1-4.fc6.ppc64.rpm
  eclipse-platform-3.2.1-4.fc6.ppc64.rpm
  eclipse-platform-sdk-3.2.1-4.fc6.ppc64.rpm
  eclipse-rcp-3.2.1-4.fc6.ppc64.rpm
  eclipse-rcp-sdk-3.2.1-4.fc6.ppc64.rpm
  eclipse-sdk-3.2.1-4.fc6.ppc64.rpm 
Comment 65 Andrew Overholt 2006-10-19 13:39:42 EDT
(In reply to comment #64)
> ----- Additional Comments From robbiew@us.ibm.com  2006-10-19 13:21 EDT -------
> Replacing the packages worked!

Great.  So you'll have to do this as a workaround for FC6 until we can get the
multilib situation sorted out and push an update.

As an aside, why do the Power team(s) within IBM not request the Eclipse
Platform team -- also within IBM -- to ship Power builds?  That isn't meant to
sound snarky - I'm genuinely curious.
Comment 66 Ben Konrath 2006-10-19 13:43:35 EDT
(In reply to comment #65)
> As an aside, why do the Power team(s) within IBM not request the Eclipse
> Platform team -- also within IBM -- to ship Power builds?  That isn't meant to
> sound snarky - I'm genuinely curious.

I'm interested too. I spent a bit of time hacking in ppc64 support - it would
have been much nicer if eclipse.org provided the ability to build on this arch.
See this bug for details:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=146083
Comment 67 Andrew Overholt 2006-10-19 13:50:20 EDT
(In reply to comment #65)
> As an aside, why do the Power team(s) within IBM not request the Eclipse
> Platform team -- also within IBM -- to ship Power builds?  That isn't meant to
> sound snarky - I'm genuinely curious.

Actually, I think that it's the usual confusion between ppc and ppc64.  Upstream
does actually release for Linux on ppc so perhaps this question is moot.
Comment 68 IBM Bug Proxy 2006-10-19 17:06:14 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-19 17:03 EDT -------
One of the main reason why we haven't provided a 64bit Eclipse, is because of
the performance hit.  32bit is faster and there really hasn't been a good case
for us to commit to supporting a 64bit version.  I'm trying to understand what
happend between FC5 and FC6 to cause this problem...could someone summarize for
me what exactly changed?  Do we need to look at providing a 64bit Eclipse now? 
Comment 69 Andrew Overholt 2006-10-19 17:10:37 EDT
(In reply to comment #68)
> I'm trying to understand what
> happend between FC5 and FC6 to cause this problem...could someone summarize for
> me what exactly changed?

I don't know for sure but I think it's a combination of anaconda using yum and
libgcj's multilib-ness.

> Do we need to look at providing a 64bit Eclipse now? 

Who's "we"?  We (Red Hat) already provide a ppc64 Eclipse SDK in Fedora by
modifying the build.  See, for example,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=146083
Comment 70 Thomas Fitzsimmons 2006-10-19 17:18:06 EDT
If ELF32 binaries are generally more performant on ppc64 than ELF64 binaries,
and there is no other compelling reason to prefer ELF64 binaries on ppc64, then
perhaps the ppc64 rpm/yum/ananconda should be made to prefer ELF32 binaries.
Comment 71 Jesse Keating 2006-10-19 17:22:46 EDT
(In reply to comment #68)
> ----- Additional Comments From robbiew@us.ibm.com  2006-10-19 17:03 EDT -------
> One of the main reason why we haven't provided a 64bit Eclipse, is because of
> the performance hit.  32bit is faster and there really hasn't been a good case
> for us to commit to supporting a 64bit version.  I'm trying to understand what
> happend between FC5 and FC6 to cause this problem...could someone summarize for
> me what exactly changed?  Do we need to look at providing a 64bit Eclipse now? 

Here is what changed.  In FC5 we had a hand maintained list of what is multilib
and what isn't.  This was bad as we had to maintain the list in many locations
and it broke.  Also there was inconsistancy between the multilib capable arches,
a package may have been multilib on x86_64 but not on ppc64.

With FC6 we developed a way to use the existance of a -devel subpackage to
consider a package multilib.  We made the -devel subpackage require its arch
specific base package component.  We depsolve from there.  This made a LOT more
packages multilib, but this is a good thing as we get ever closer to a full
multilib development and even runtime environment.  We still have to maintain a
list of MORE packages to be multilib, ones that don't have -devel subpackages. 
And to date, we've only had to blacklist the kernel (on all but ppc64) from
being multilib.  This is a vast improvement from before.
Comment 72 IBM Bug Proxy 2006-10-19 17:26:26 EDT
----- Additional Comments From robbiew@us.ibm.com  2006-10-19 17:21 EDT -------
"We" being IBM. 
Comment 73 Ben Konrath 2006-10-23 14:41:31 EDT
(In reply to comment #70)
> If ELF32 binaries are generally more performant on ppc64 than ELF64 binaries,
> and there is no other compelling reason to prefer ELF64 binaries on ppc64, then
> perhaps the ppc64 rpm/yum/ananconda should be made to prefer ELF32 binaries.

This seems reasonable. Is it possible to do this?

If we do have to make eclipse multilib compatible, what's the deadline?

Comment 74 Jesse Keating 2006-10-23 16:07:45 EDT
I don't think it will be possible to change RPMs way of doing things on ppc this
late in the game.  As for a deadline, I would assume the Beta2 deadline.
Comment 75 Ben Konrath 2006-10-23 16:20:00 EDT
(In reply to comment #74)
> I don't think it will be possible to change RPMs way of doing things on ppc this
> late in the game.

Does this mean we will be able to  back out the multilib changes for RHEL6?
Comment 76 Jesse Keating 2006-10-23 17:28:04 EDT
I honestly don't know.  I don't grasp all the issues around ppc32 vs ppc64 and
what all will BREAK if we reverse the way it is handled.  More of a question for
the Arch owner (do we have one?) and the rpm maintainer.
Comment 77 Andrew Overholt 2006-11-04 17:11:37 EST
I think this is fixed with today's rawhide (2006-11-04).  I've tested
eclipse-1:3.2.1-15.fc7 on ppc64 and x86_64 in both the biarch (both installed)
and the 32-bit cases and it works fine.

The only issue I could find was that the embedded browser didn't work on ppc64
but we should open a new bug for that one if it isn't something screwy with my
test system.

Can the reporter please verify?  Thanks.
Comment 78 Ben Konrath 2006-11-05 12:12:25 EST
Glen, you should be able to use FC6 to test the Eclipse packages from rawhide.
Comment 79 Andrew Overholt 2006-11-06 11:40:03 EST
Jesse:  can we now add the ppc64 packages to the ppc repo?  Thanks.
Comment 80 Ben Konrath 2006-11-08 00:06:34 EST
(In reply to comment #79)
> Jesse:  can we now add the ppc64 packages to the ppc repo?  Thanks.

This is for rawhide. We need to build this in fc6 before it's ready for that
collection.
Comment 81 IBM Bug Proxy 2006-11-10 09:46:09 EST
----- Additional Comments From robbiew@us.ibm.com  2006-11-10 09:40 EDT -------
Sorry for the delay.  We are currently closing out on some other work, but will
verify eclipse-1:3.2.1-15.fc7 as soon we can. 
Comment 82 Ben Konrath 2006-11-10 14:00:21 EST
No worries on the delay. The lastest fixes for this are in 3.2.1-17.fc7 and
.2.1-17.fc6. I'm in the process of getting the fixed FC-6 into the
updates-testing repo. I'll post back when the packages are there, but you should
be able to use the fc7 packages on FC-6.
Comment 83 Andrew Overholt 2006-11-16 18:20:50 EST
(In reply to comment #77)
> The only issue I could find was that the embedded browser didn't work on ppc64
> but we should open a new bug for that one if it isn't something screwy with my
> test system.

I tried to investigate this a bit today and I think it is indeed because I only
had the 32-bit firefox installed.

When you get a chance to test, can you see if the embedded web browser works?

Thanks.
Comment 84 Andrew Overholt 2006-11-16 19:24:52 EST
(In reply to comment #83)
> (In reply to comment #77)
> > The only issue I could find was that the embedded browser didn't work on ppc64
> > but we should open a new bug for that one if it isn't something screwy with my
> > test system.
> 
> I tried to investigate this a bit today and I think it is indeed because I only
> had the 32-bit firefox installed.

Nevermind, I think I have found the problem.  I'll test when the build is finished.
Comment 85 Andrew Overholt 2006-11-17 13:55:44 EST
Yup, 3.2.1-20.fc7 (in tomorrow's rawhide push) will have the fix.  It was a
simple matter of needing to add ppc64 (__powerpc64__) to the list of arches that
need to look at gre64.conf instead of gre.conf.
Comment 86 Ben Konrath 2006-12-06 14:12:54 EST
We just pushed 3.2.1-23.fc6 to FC-6 updates which should have a fix for this.
Could someone verify this fix? Thanks, Ben
Comment 87 IBM Bug Proxy 2006-12-06 15:25:41 EST
----- Additional Comments From robbiew@us.ibm.com  2006-12-06 15:22 EDT -------
We will test and provide results as soon as possible. 
Comment 88 IBM Bug Proxy 2006-12-12 15:55:55 EST
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Submitting Project|Cell SDK                    |LTC Quality




------- Additional Comments From richardm@br.ibm.com  2006-12-12 15:53 EDT -------
I ran fedora-eclipse in a FC6-test3 with all patches applied, but eclipse didn't
work either.
However, after replacing the packages (as described in Robert V. Williamson's
workaround comment #61), it worked.

I still must do some tests with the IBM JVM and fedora eclipse to see if it
works (in a patched system, but without replacing the packages) and as soon as I
have some news, I'll post them here. 
Comment 89 IBM Bug Proxy 2006-12-13 06:40:43 EST
----- Additional Comments From richardm@br.ibm.com  2006-12-13 06:35 EDT -------
Some fixes in my previous message:
* The system used was a FC6 final, NOT test3.
* The system was not patched. It was updated (using yum update)
* The Fedora Eclipse version used was 3.2.1-23.fc6 
Comment 90 IBM Bug Proxy 2006-12-13 15:01:04 EST
Created attachment 143548 [details]
log.eclipsefc6
Comment 91 IBM Bug Proxy 2006-12-13 15:01:31 EST
----- Additional Comments From richardm@br.ibm.com  2006-12-13 14:54 EDT -------
 
Messages printed by eclipse on the shell where I started it

Fedora eclipse on FC6 - using gcj (as described in message #85) - ran without
problems except for some messages in the command-line shell where I launched
eclipse application. The attachment shows these messages 
Comment 92 Ben Konrath 2006-12-13 22:59:01 EST
The log message looks like Fedora Eclipse shouldn't be working. Can you send
output of this:

rpm -qa | grep eclipse 

And can you post the complete output of 'eclipse -consolelog'? Thanks.
Comment 93 IBM Bug Proxy 2006-12-14 08:16:01 EST
Created attachment 143623 [details]
eclipse-test.txt
Comment 94 IBM Bug Proxy 2006-12-14 08:16:49 EST
----- Additional Comments From lagarcia@br.ibm.com  2006-12-14 08:09 EDT -------
 
Various Eclipse and JVMs tests

I am attaching a file with the final results of a set of tests Richard and I
done in the past days with different configurations of Eclipse and JVMs.

The tests were done in a fresh Fedora Core 6 64 bit installation on a OpenPower
720 LPAR. Although we installed a 64 bit Linux, Anaconda installed a 32 bit
Eclipse in our machine. After doing 'yum update' we end with Fedora Eclipse
3.2.1-23.fc6.ppc, which was not working because GCJ 32 bits was installed by
Anaconda but it was substituted by GCJ 64 bit according to what was already
discussed in this bug. We still got the error first described in this bug. This
was expected, as 32 and 64 bit mixed combination should fail.

Afterwards, we uninstalled Eclipse 3.2.1-23.fc6.ppc and installed
3.2.1-23.fc6.ppc64 version. From this point on, GCJ 64 bit and Fedora Eclipse
64 bit worked fine.

In the attached file there are more results with 32 bit and 64 bit mixed
configurations. All the results were just as expected.

IMHO, the only problem we have here is that Anaconda is installing a 32 bit
Fedora Eclipse in a 64 bit Linux environment. Even if we try 'yum update' after
the installation, we still have a 32 bit Fedora Eclipse that won't work with 64
bit GCJ. So, the user has to uninstall the 32 bit version of Fedora Eclipse and
install the 64 bit version manually. I think all this conclusions were already
decribed here, sorry for duplicating my conclusions.

Anyway, I don't know if there is a way to correct this for Fedora Core 6
anymore. If you want us to do any other tests, please let us know. 
Comment 95 Andrew Overholt 2006-12-18 11:14:43 EST
> IMHO, the only problem we have here is that Anaconda is installing a 32 bit
> Fedora Eclipse in a 64 bit Linux environment.

Yeah, that's because anaconda that shipped with FC6 didn't have eclipse in the
multilib list.  And just clarify:  you're using the 32-bit ppc installation, right?

> Even if we try 'yum update' after
> the installation, we still have a 32 bit Fedora Eclipse that won't work with 
> 64 bit GCJ.

I thought that the eclipse RPMs were added to the multilib list.  Jesse?
Comment 96 IBM Bug Proxy 2006-12-18 13:55:38 EST
------- Additional Comments From lagarcia@br.ibm.com  2006-12-18 13:51 EDT -------
(In reply to comment #90)
> ----- Additional Comments From overholt@redhat.com  2006-12-18 11:14 EST -------
> > IMHO, the only problem we have here is that Anaconda is installing a 32 bit
> > Fedora Eclipse in a 64 bit Linux environment.
> 
> Yeah, that's because anaconda that shipped with FC6 didn't have eclipse in the
> multilib list.  And just clarify:  you're using the 32-bit ppc installation,
right?

No. AFAIK, we are using a 64-bit ppc installation.

We installed the system from CDs and when the first intallation CD booted I type
'linux64' in yaboot prompt.

> 
> > Even if we try 'yum update' after
> > the installation, we still have a 32 bit Fedora Eclipse that won't work with
> > 64 bit GCJ.
> 
> I thought that the eclipse RPMs were added to the multilib list.  Jesse?
> 
> -- 
Comment 97 Andrew Overholt 2006-12-18 14:39:35 EST
I don't think we ship ppc64 bootable installation media.  But this whole ppc vs.
ppc64 distinction is confusing.

Either way, we just need to make sure that eclipse* are added to the multilib
list for the installer and yum.
Comment 98 Ben Konrath 2006-12-18 15:05:18 EST
After reading comment #94 I'm wondering if a yum update will pull in the 64-bit
packages if the 32-bit packages are already installed and eclipse is in the
multilib list? Or will the 64-bit packages need to be explicitly installed? 

But I agree with comment #97, we need to find out if the 3.2.1-23.fc6 packages
are in the multilib list before we look at other things.
Comment 99 Jesse Keating 2006-12-18 15:18:29 EST
(In reply to comment #97)
> I don't think we ship ppc64 bootable installation media.  But this whole ppc vs.
> ppc64 distinction is confusing.
> 
> Either way, we just need to make sure that eclipse* are added to the multilib
> list for the installer and yum.

Yes, we do ship ppc64 bootable disks.  The PPC disks we produce for Fedora are
both ppc32 and ppc64 bootable.  In fact, its runtime detectable.  If the CD
detects your on ppc32 hardware, you only get the ppc32 option.  Same for ppc64.



(In reply to comment #98)
> After reading comment #94 I'm wondering if a yum update will pull in the 64-bit
> packages if the 32-bit packages are already installed and eclipse is in the
> multilib list? Or will the 64-bit packages need to be explicitly installed? 
> 
> But I agree with comment #97, we need to find out if the 3.2.1-23.fc6 packages
> are in the multilib list before we look at other things.

If a package is requested by name, and both arches are available, both will be
installed.  If a part of a package (say a library) is requested for a dep, only
the package which holds that library will be brought in, not the other arch package.
Comment 100 Ben Konrath 2006-12-20 18:16:28 EST
I tried to get eclipse ppc64 going from the updates repo and had a problem. 'yum
update' didn't bring in the ppc64 packages and when I did 'yum install
eclipse-sdk.ppc64' after the 'yum update' I got this error:

Transaction Check Error:   file
/usr/share/eclipse/features/org.eclipse.rcp_3.2.1.r321_v20060801-clWbqCmjexIWDqg/feature.xml
from install of eclipse-rcp-3.2.1-23.fc6 conflicts with file from package
eclipse-rcp-3.2.1-23.fc6
  file /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar
from install of eclipse-rcp-3.2.1-23.fc6 conflicts with file from package
eclipse-rcp-3.2.1-23.fc6
  file /usr/share/eclipse/plugins/org.eclipse.osgi_3.2.1.R32x_v20060919.jar from
install of eclipse-rcp-3.2.1-23.fc6 conflicts with file from package
eclipse-rcp-3.2.1-23.fc6

So it seems there is still an issue here. For now you should be able to do what
is described in comment #94 to get this working. I'll investigate this shortly
and possibly push a new update.
Comment 101 Ben Konrath 2007-01-31 17:34:47 EST
Changing version to fc6 because I'm fixing this bug in an upcoming update to
fc6. I'll fix this in rawhide too.
Comment 102 Ben Konrath 2007-02-23 11:49:48 EST
This is fixed in the latest update: 3.2.2-1.fc6 Feel free to re-open if you
still have problems.

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