Description of problem: Dell Diags Apps need 32bit "libgcj-3.4.3" package containing library "libgcj.so.5" on RHEL5 installation CD. This library is crtical for running the App and is not provided as part of compat libraries on RHEL5 Alpha1 or FC6 Test2 installation CDs. Version-Release number of selected component (if applicable): libgcj-3.4.3 Actual results: libgcj-4.1.1-20.i386.rpm is present Expected results: libgcj-3.4.3.i386.rpm is present
Not in Bet1. Can we expect to see this in Beta2?
Reassinging to Jakub. Jakub, are we shipping libgcj-compat packages in RHEL-5?
May I also request that this (libgcj-compat) be added to the base package list when it in fact is added ? ;-)
Dell is asking that we include libgcj-3.4.3 (which contains library libgcj.so.5) in RHEL5 for backwards compatibility as we do in RHEL4. Without it, their RHEL4 based diagnostics don't work and the effort required to upgrade them to use libgcj-4.1.1-20 is not containable for RHEL5 GA. Dell considers this a regression. Jakub, can you provide me with a quick estimate of the engineering effort required to provide libgcj-3.4.3 as well in RHEL5 so I can escalate the issue for beta2 inclusion.
No response from Engineering but Dell feels this is critical to RHEL5. Escalating. See comment #4 for details.
Pinged Jakub.
On Thu, 28 Sep 2006 11:09:44, jakub wrote: > I strongly prefer not to include it and the java-project > folks share this opinion with me, libgcj in RHEL4 was way too premature to > include it as compat libs. > > Can't Dell include the library themselves? Or, can it be just interpreted > in RHEL5 (i.e. run from *.jar rather than *.so)? > > Jakub Dell, comments....
Unfortunately, Red Hat's marketing department has made promises to ISVs that RHEL(N) will include compatability libraries for apps built on RHEL(N-1) and RHEL(N-2) so that ISVs' applications may continue to run unmodified. This was part of the reason they were willing to jump from LSB 1.3 to 2.0; the promises made by LSB were "weaker" than the promises made by RH marketing. Unfortunately, that puts RH engineers in a bind, including and maintaining libraries far longer than you'd like. Dell strongly prefers to hold Red Hat to this promise. It affects not only Dell shipped products, but we suspect those of the larger ISV community as well. Dell doesn't want to include Red Hat-produced RPMs on Dell-specific media, with all the security concerns that raises of us distributing those separately and thus being responsible for updating customers in the field.
LSB s/2.0/3.0/ above.
Can somebody find out what marketing actually promissed? I very much doubt we have promissed all compatibility libs, there are several hundreds libraries and we definitely aren't including hundreds of compatibility packages. I'm sure we have promissed glibc, libgcc, libstdc++, libX11 etc., but I doubt that includes libgcj. libgcj certainly isn't covered by either LSB 2.0 or LSB 3.0.
The promise for app compatibility comes from: http://www.redhat.com/f/pdf/rhel4/AppCompat.pdf
In general we promise -2 versions but we reserver the right to decide on a per component base. I think we need to carefully evaluate the options: We told partners like Dell to use gcj vs. proprietary JDKs. It might hurt our cause if we force them to recompile for RHEL5 now (if that is the impact). So I would prefer to make sure that a gcj compiled Java app from at least RHEL4 still runs on RHEL5, if possible.
libgcj is certainly not covered by LSB, neither 1.3, nor 2.0, nor 3.0 and in http://www.redhat.com/f/pdf/rhel4/AppCompat.pdf isn't listed among core libraries either: Core Libraries Red Hat defines a set of libraries whose APIs and ABIs will be preserved for each architecture across major releases of the distribution. To ensure application runtime compatibility across major releases (for example between Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4), application developers are encouraged to limit their applications to linking against this limited set of libraries. For Red Hat Enterprise Linux, the core set of libraries includes: libc, libgcc, libstdc++, libdl, libm, libutil, libcrypt, libz, libpthread, libncurses libX11, libXext, libXt, libICE, libSM, libGL libgtk, libgdk, libgdk_pixmap, libpango , libatk , libglib, libgmodule, libgthread, libgnomeprint, libgnomeprintui, libgconf, libglade If an application can not limit itself to the interfaces of these core libraries, then to ensure compatibility across major releases, the application should bundle the additional required libraries as part of the application itself. In that case, the bundled libraries must themselves use only the interfaces provided by the core libraries. Can you please explain where we promissed libgcj compatibility accross RHEL major versions? We weren't shipping RHEL3 libgcj compatibility libraries in RHEL4 either BTW.
I'd say we should consider adding libgcj_bc to the list of Core libraries for RHEL5 and that way promise backwards compatibility with -findirect-dispatch compiled/linked RHEL5 apps in RHEL6. My understanding is that libgcj_bc.so.1 will maintain a stable ABI and therefore it shouldn't be hard to fulfill those promisses. But really supporting the already unsupportable GCC 3.4.x Java stack for another 7 years is a terrible idea. We ourselves had to migrate most of the RHEL apps written in Java to libgcj4 (first to 4.0.x and in U4 to 4.1.x based libgcj).
Supporting binary compatibility in gcj is definitely our plan. The only potential problem I know is this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377 We might be able to fix this in a way that lets old objects continue to work. CCing Andrew for comments.
I suppose this is the key question now: when do we believe that our BC ABI is sufficiently stable to guarantee support for the future? I guess it's been used such a lot and in varying scenarions for long enough now that we really _do_ believe it. But we can't make the reverse promise: that new binaries will work on old libraries. This is because we can extend the ABI, which still being compatible with old binaries. This is normal, I think.
Whoa.... In reviewing the above comments (13-19) with QE's Jay and James, we're confused. Could Engineering state its position on including libgcj-3.4.3 for compatibility and either ACK or NAK the bug for RHEL5 GA consideration. Per my comment #4, if we do not include this library, Dell diagnostics will not work and they do not have time to upgrade them to work with later versions of the library (libgcj-4.1.1-20) and make RHEL5GA. Per comment #9, Dell does not want to ship and support this library independent of Red Hat. Furthermore, they believe other ISVs will have similar problems if we do not include it in RHEL5. Removing the escalation request until this is resolved.
Comments 16-18 talk about gcc 4.1.1 stuff (so whether RHEL5 should say that RHEL6 will have RHEL5 java compatibility or not). I'm all for NACKing including 3.4.x-RH java compatibility in RHEL5, but will let the Java folks comment on it. "Since we are no longer compatible with RHEL3 and RHEL4" comment is misleading, we never were totally backwards compatible, only for the core libraries. We ship order of magnitude more libraries that are never backward compatible between RHEL versions. libgcj has never been declared in the core library set, and rightly so.
> Could Engineering state its position on including libgcj-3.4.3 > for compatibility and either ACK or NAK the bug for RHEL5 GA > consideration. We don't want to include libgcj-3.4.3. We could consider binary compatibility starting with RHEL 5.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Reopening at Dell's request. We need a solution that will allow the same binary diagnostic apps to run on RHEL4 and RHEL5. Whether this means a Red Hat or a Dell provided solution is TBD. The bug remains open to track the solution.
Lost a posting here???? Amit, regarding justification, Jakub says in comment #16 above: "We ourselves had to migrate most of the RHEL apps written in Java to libgcj4 (first to 4.0.x and in U4 to 4.1.x based libgcj)" and "...supporting the already unsupportable GCC 3.4.x Java stack for another 7 years is a terrible idea." I will ask if we can put libgcj-3.4.3 on the "Supplemental CD" so Dell can use it until they can migrate their applications.... but this gets back into the "supported vs unsupported" discussions we had in RHEL4 development when we decided to drop the "unsupported" directories because multiple big customers said "you ship it, you therefore will support it."
Dell Diags team has decided to carry a copy of the compat gcj package (more specifically libgcj.so.5 file from RHEL4) as a part of their application thereby working around this fiasco. Please close this feature request as it's N/A anymore.
Thanks.