Bug 207016
Summary: | Eclipse packages are not multilib | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> | ||||||||||
Component: | eclipse | Assignee: | Ben Konrath <ben> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||||
Severity: | urgent | Docs Contact: | |||||||||||
Priority: | high | ||||||||||||
Version: | 6 | CC: | aph, dcantrell, fitzsim, jakub, katzj, notting, tromey | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | ppc64 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | 3.2.2-1.fc6 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2007-02-23 16:49:48 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 212878, 212879 | ||||||||||||
Attachments: |
|
Description
IBM Bug Proxy
2006-09-18 19:31:23 UTC
What architecture are you running on? (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. ----- Additional Comments From robbiew.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. 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. ----- Additional Comments From robbiew.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? changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cjashfor.com ------- Additional Comments From cjashfor.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. (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:" (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. ----- Additional Comments From robbiew.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 ----- Additional Comments From robbiew.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 (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. (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 ----- Additional Comments From robbiew.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. 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? 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. 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?
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. 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. (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. 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 (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. ----- Additional Comments From robbiew.com 2006-10-13 11:58 EDT ------- Should we re-test for this in FC6-pre? (In reply to comment #30) > ----- Additional Comments From robbiew.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. (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. changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agodwin.com ------- Additional Comments From agodwin.com 2006-10-17 15:37 EDT ------- adding myself to CC: list - need this fix for SDK2.0 IVT testing 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)? 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... 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. 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?
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'? most likely because eclipse-sdk isn't considered multilib (as I'm assuming there is no eclipse-sdk-devel package) 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? 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. (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? 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. 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. 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). 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. 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? 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? It would break frysk. Please, supply 64-bit Eclipse and be done with it. 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. (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. > 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.
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... (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. 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 ----- Additional Comments From robbiew.com 2006-10-19 12:29 EDT ------- doing this now...will update once complete (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. 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. (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. ----- Additional Comments From robbiew.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 (In reply to comment #64) > ----- Additional Comments From robbiew.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. (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 (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. ----- Additional Comments From robbiew.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? (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 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. (In reply to comment #68) > ----- Additional Comments From robbiew.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. ----- Additional Comments From robbiew.com 2006-10-19 17:21 EDT ------- "We" being IBM. (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? 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. (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? 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. 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. Glen, you should be able to use FC6 to test the Eclipse packages from rawhide. Jesse: can we now add the ppc64 packages to the ppc repo? Thanks. (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. ----- Additional Comments From robbiew.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. 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. (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. (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. 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. 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 ----- Additional Comments From robbiew.com 2006-12-06 15:22 EDT ------- We will test and provide results as soon as possible. changed: What |Removed |Added ---------------------------------------------------------------------------- Submitting Project|Cell SDK |LTC Quality ------- Additional Comments From richardm.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. ----- Additional Comments From richardm.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 Created attachment 143548 [details]
log.eclipsefc6
----- Additional Comments From richardm.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 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. Created attachment 143623 [details]
eclipse-test.txt
----- Additional Comments From lagarcia.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. > 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? ------- Additional Comments From lagarcia.com 2006-12-18 13:51 EDT ------- (In reply to comment #90) > ----- Additional Comments From overholt 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? > > -- 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. 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. (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. 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. Changing version to fc6 because I'm fixing this bug in an upcoming update to fc6. I'll fix this in rawhide too. This is fixed in the latest update: 3.2.2-1.fc6 Feel free to re-open if you still have problems. |