Red Hat Bugzilla – Bug 204708
32bit libgcj compat libraries needed with RHEL5
Last modified: 2010-10-22 01:53:27 EDT
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-4.1.1-20.i386.rpm is present
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.
On Thu, 28 Sep 2006 11:09:44, firstname.lastname@example.org wrote:
> I strongly prefer not to include it and the email@example.com
> 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)?
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
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:
In general we promise -2 versions but we reserver the right to decide on a per
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
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,
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
Supporting binary compatibility in gcj is definitely our plan.
The only potential problem I know is this bug:
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.
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
> Could Engineering state its position on including libgcj-3.4.3
> for compatibility and either ACK or NAK the bug for RHEL5 GA
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.