Bug 204708 - 32bit libgcj compat libraries needed with RHEL5
32bit libgcj compat libraries needed with RHEL5
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc (Show other bugs)
5.0
All Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
: FutureFeature, Reopened
Depends On:
Blocks: 184191
  Show dependency treegraph
 
Reported: 2006-08-30 18:50 EDT by Amit Bhutani
Modified: 2010-10-22 01:53 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-19 05:50:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Amit Bhutani 2006-08-30 18:50:33 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-3.4.3

Actual results:
libgcj-4.1.1-20.i386.rpm is present

Expected results:
libgcj-3.4.3.i386.rpm is present
Comment 1 Amit Bhutani 2006-09-05 17:49:19 EDT
Not in Bet1. Can we expect to see this in Beta2?
Comment 2 Thomas Fitzsimmons 2006-09-08 09:47:08 EDT
Reassinging to Jakub.  Jakub, are we shipping libgcj-compat packages in RHEL-5?
Comment 3 Amit Bhutani 2006-09-13 19:19:19 EDT
May I also request that this (libgcj-compat) be added to the base package list 
when it in fact is added ? ;-)
Comment 4 Larry Troan 2006-09-14 09:26:34 EDT
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.
Comment 5 Larry Troan 2006-09-19 09:42:08 EDT
No response from Engineering but Dell feels this is critical to RHEL5.
Escalating. See comment #4 for details.
Comment 7 Larry Troan 2006-09-28 10:55:09 EDT
Pinged Jakub. 
Comment 8 Larry Troan 2006-09-28 12:55:27 EDT
On Thu, 28 Sep 2006 11:09:44, jakub@redhat.com wrote:
> I strongly prefer not to include it and the java-project@redhat.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)?
>
>       Jakub

Dell, comments....
Comment 9 Matt Domsch 2006-09-28 13:33:12 EDT
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.
Comment 10 Matt Domsch 2006-09-28 13:34:32 EDT
LSB s/2.0/3.0/ above.
Comment 11 Jakub Jelinek 2006-09-28 13:45:14 EDT
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.
Comment 13 Daniel Riek 2006-09-29 11:54:05 EDT
The promise for app compatibility comes from:
http://www.redhat.com/f/pdf/rhel4/AppCompat.pdf
Comment 14 Daniel Riek 2006-09-29 12:04:18 EDT
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.
Comment 15 Jakub Jelinek 2006-09-29 12:08:47 EDT
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.
Comment 16 Jakub Jelinek 2006-09-29 12:16:03 EDT
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).
Comment 17 Tom Tromey 2006-09-29 15:28:47 EDT
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.
Comment 18 Andrew Haley 2006-09-30 05:22:02 EDT
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.
Comment 20 Larry Troan 2006-10-04 08:45:00 EDT
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.
Comment 21 Jakub Jelinek 2006-10-04 09:48:01 EDT
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.
Comment 22 Tom Tromey 2006-10-04 18:49:42 EDT
> 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.
Comment 23 RHEL Product and Program Management 2006-10-05 04:45:18 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 24 Larry Troan 2006-10-05 15:25:21 EDT
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.
Comment 26 Larry Troan 2006-10-12 08:31:29 EDT
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."
Comment 28 Amit Bhutani 2006-10-18 23:32:04 EDT
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.
Comment 29 Jakub Jelinek 2006-10-19 05:50:25 EDT
Thanks.

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