[N O T E : T H I S   I S   N O T   A   D U P L I C A T E   O F   4 6 8 7 8 1 4]
[                    PLEASE SEE NOTES IN EVALUATION                           ]




FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

I got this output by running java on a linux box that has gcc2.96.3, not 3.1.


Kondara MNU/Linux 2.1 with some CVS updates.
Kernel: Linux 2.4.18
glibc: 2.2.5
gcc: *3.1* (provides libstdc++.so.4.0.0)




A DESCRIPTION OF THE PROBLEM :
Java2 SDK 1.4 does not run at all on some Linux box that only has newer libstdc++.
Newer version of gcc supplies libstdc++.so.4.0.0, and is not compatible with
older ones.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Install gcc 3.0 or higher.
2. Install Java2 SDK 1.4.
   RPM complains about failed dependencies:
   libstdc++-libc6.1-1.so.2 is needed by...
3. Install Java2 SDK 1.4 with ignoring dependencies.
   (Using --nodeps) Of course this would not help at all.
4. run java -version. Then it complains:
   failed ../jre/lib/i386/client/libjvm.so. because libstdc++-libc6.1-1.so.2:
cannot open shared object file: No such file or directory.


This bug can be reproduced always.

CUSTOMER WORKAROUND :
Copy older libstdc++.so by hand from older gcc package.
(Review ID: 147011) 
======================================================================

N/A

There are multiple issues surrounding libstdc++.so, moving to use a different
gcc to build JDK doesn't solve all of the problems - unless we can provide 
binaries for every possible gcc version. We'd like to keep a single binary 
build to simplify testing and deployment, so that's not what we want to do. 

We've implemented a couple of changes in 1.4.2 to solve the compatibility
issues and they were put back by different bug IDs. But since this bug is 
one of the top bugs on JDC, here I'll explain the changes and possible 
workarounds before 1.4.2 is released:

1. JDK requires libstdc++-libc6.1-1.so.2

PROBLEM

JDK is linked with libstdc++-libc6.1-1.so.2, and many new Linux distributions
do not have this library installed by default. As the result, you'll see
error message similar to this:

Error: failed ../jre/lib/i386/client/libjvm.so. because libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory.

FIX

To fix this, we statically link libstdc++.so in JDK, so there is no requirement
on user side to have the library installed. It is implemented for HotSpot VM
in 1.4.1 and for the rest of JDK in 1.4.2.

WORKAROUND

User has to install libstdc++-libc6.1-1.so.2 manually. For example, Redhat
Linux has this library in the "compat-libstdc++" package.

2. Incompatibility in C++ ABI

PROBLEM

The binary interface of libstdc++ has been constantly changing in the past
two years, if user JNI code is written in C++ and not compiled by the same
compiler we used to build JDK (i.e. egcs-2.91), at runtime, there will be
two incompatible libstdc++.so being loaded into memory at the same time.

That isn't healthy, in particular, when two libraries have common symbols
(yes, there are many common symbols between different libstdc++.so), symbols
from the first loaded library will be used to resolve all references. This can
lead to crashes or aborts.

FIX

We really can't fix imcompatibility issues for C++ ABI. What we did for
1.4.2 is just trying to work around the problem. Please see 4776723 and
4706607. We statically link the C++ runtime in JDK and enabled linker
script to hide symbols from libstdc++ and other internal symbols. As the
result, those symbols become invisible to JNI code, and when some native
code needs to call into C++ runtime, the call will be resolved with
the appropriate libstdc++.so. There are still two libstdc++.so being
loaded at the same time, but it should be benign.

In the meantime, user could try one of the following workarounds:

WORKAROUNDS

+ If you have access to the source code of the JNI library and can rebuild
  it, build it on Redhat 6.2. Then the JNI bits will be linked against the
  same C++ runtime that is being used by JDK, and there will be no symbol
  conflicts. This is the safest solution. You can continue to deploy on
  non-RH-6.2 systems (e.g. Redhat 7.x) and have the added benefit that you
  can deploy on earlier platforms.

+ If you can rebuild the library, but can't build it on Redhat 6.2,
  you can use gcc (not g++) to link the binary, you also need to add
  "-Wl,-Bsymbolic -Wl,-Bstatic -lstdc++, -Wl,-Bdynamic" to the command
  line to statically link with the correct libstdc++ and force linker
  to resolve symbols within the library.

+ If for some reason you cannot rebuild the library, you can preload
  the libstdc++.so that is used by your JNI library. You need to run
  "ldd" first on the library to figure out which libstdc++.so will
  be used, then set LD_PRELOAD to include it. This will cause all
  reference to the C++ runtime to be resolved by the preloaded libstdc++.so.
  This can work around most of the problems, and easy to test.

3. Change in C++ mangling rules

PROBLEM

This is actually part of the ABI changes, but since it has a different
symptom and requires different solution, I list it here separately.

With gcc-3.x, the format for a mangled C++ symbol has changed.  For example,
A::foo(int) is encoded as foo__1Ai by gcc-2.x and as _ZN1A3fooEi by gcc-3.x.
If library X imports C++ symbols from library Y and X is built by gcc-2.x,
now you try to run X with a version of Y that is built by gcc-3.x, you'll
get errors on unsolved symbols; because, for example, X is trying to call
foo__1Ai but Y only provides _ZN1A3fooEi. That is what's happening when
you use java plugin in a browser built by gcc-3.x.

FIX

Don't import C++ symbols directly.

WORKAROUNDS

No.

 xxxxx@xxxxx  2002-12-16

--------------------------------------------------------

One more ABI compatibility problem. This time it's with Java plugin only.
Apparently in a C++ object which contains virtual functions, its vptr
points to different place when the code is compiled by gcc-2.9x or gcc-3.x.
This is causing problems in Java plugin (see 4687814) because the OJI
interface is using virtual functions extensively between browser (Mozilla) 
and plugin. There is really no way to fix it other than building the plugin 
with gcc-3.2 (or modifying OJI). This is not a problem with other part
of JDK because we don't use virtual functions to communicate with other
libraries.

 xxxxx@xxxxx  2003-03-31

--------------------------------------------------------

So here's what we did in Mantis in an attempt to resolve the gcc compatibility
issues:

(1) C++ runtime (aka libstdc++.so) is statically linked with JDK. When you 
    install JDK or JRE, there is no requirement on the backward compatibility
    library libstdc++-libc6.1-1.so.2

(2) Linker mapfiles and versioning have been enabled. C++ symbols due to 
    static link in (1) and also VM internal symbols are now hidden. This is
    necessary to avoid symbol conflicts between different libstdc++ versions.
    But if you try to access VM internal symbol directly in a program, it 
    will not work with 1.4.2. This change can also improve VM performance
    (due to smaller dynamic symbol table), but at a cost of less accurate 
    symbol lookup after crash.

(3) 1.4.2 will have two libjavaplugin_oji.so files, one is built by gcc-2.91
    and the other one by gcc-3.2. If you are using gcc-3 built mozilla, use
    the one in "jre/plugin/i386/ns610-gcc32" directory. Otherwise, use the
    one in "jre/plugin/i386/ns610"

I'm now closing this one as "fixed". Mantis-beta should be out very soon, and
the work (except (3) because it has other dependencies) has been backported
to 1.4.1_03. If you continue to see compatibility problems, feel free to let 
me know (hui dot huang at sun dot com).

 xxxxx@xxxxx  2003-03-31

---------------------------------------------------------

 xxxxx@xxxxx  suggested to change bug status to duplicate, as
there is no code change associated with this bug ID. I have marked it as a
duplicate of 4687814 to make it easier tracking code changes.

But please note, this bug is really not a duplicate of 4687814. It's
a tracking bug for C++ compatibility issues, 4687814 is only part of
the problem. Fixes have been delivered under the following bug IDs:

         4776723, 4706607, 4665166, 4687814, 4791798

 xxxxx@xxxxx  2003-04-01

same here.... trying to work a near-to-standard-compliant
c++ compiler ( gcc3.1 ) ,and i can't use the java sdk... so
why don't offer a gcc3.1-friendly version? it shouldn't be
so hard to recompile..

please do a new Java SDK, we need it ! 

This is a show stopper bug for us in our transition of all
our developer machines from Windows to Linux. I've been due
to get a new machine for two weeks and was informed today
that I could not have a machine because the Linux we use
(the very latest Mandrake) had libraries which were
incompatible with Java and thus I had to stay put on Windows.

Now, neither you nor I want me to be stuck on a Microsoft
product do you?

Yes please do provide a java runtime built with gcc 3.1 and it's libstdc++.

The workaround of copying an older libstdc++ does NOT work
on any of 10+ Linux machines at my company. This issue is
killing us. We can't run a current Linux version because Sun
is dragging their feet on a recompile, of all things. Since
Java development is our job, this is putting us between a
rock and a hard place. Going forward, we're also in a bad
place, since all of the major distributions we deal with are
converting to gcc3.1, including Mandrake, SuSE, Caldera,
TurboLinux, and so forth.

Please, all we're asking for is a recompile, with a little
bit of patching to make it compile against gcc3.1 and
libstdc++.so.4.

Please provide code that works with GCC-3.1

From mailling list info, many linux distro's are now using
gcc-3.1, and if they are not now, they apperantly will be
within a short time!

We use Linux a lot as our platform, and I am afraid we may 
find this problematical soon.
Please correct that!

Further to all the existing comments, whacking in a 2.x
libstdc++ is not all that feasible for everyone.  Doing that
requires some considerable care, non experts will simply be
unable to do it and hence unable to run Java.  Compiling for
a 3.1 target has not been an issue for any of the software
I've just finished rebuilding.  Come on Sun, quit stuffing
around!

This is a big problem if you are using JNI to link to other 
C++ applications. You cannot mix C++ compiled with gcc 2 
and gcc 3 in the same application, so if you have a library 
compiled with gcc 3 it is not possible to use if via JNI 
from Java.

Thanks very much for the comments here and on JavaLobby.
Just want to let you know that we are well aware of the
compatibility issues surrounding different gcc versions. 
The problem is that the C++ ABI keeps changing between
different versions of gcc. If we move to use gcc-3.1 to
build JDK (in fact, 1.4.1 source has been cleaned for the 
new gcc), it will not work with many existing applications
(e.g. plugin will not work on mozilla). That would be
unacceptable to many other folks who still rely on the old
system.

That being said, we are surely trying to find a release as
the candidate for the transition to gcc-3.x. It would depend
on how fast the community is switching to gcc-3.x. Right
now, we are looking at 1.4.2 being the transition release.
If you feel strongly 1.4.1 should be the one (btw, 1.4.1
beta is just released today), please share your thoughts
here. We'd love to hear.

Just a note on statically linking libstdc++. Yes, that will
solve the dependence on libstdc++-libc6.1-1.so.2, and we 
are doing this for 1.4.1. But keep in mind that could 
cause other problems, as you might end up having two
incompatible C++ runtime in the memory. That isn't healthy.

Again, thanks for all the comments and suggestions.

This is a major problem for us also.
I don't see why sun do not release the source under a more
open license.  What have they got to lose?  It would
certainly reaffirm java as a more attractive development
option than .NET.

This is huge for my company.  We made the mistake of moving 
to jdk 1.4 and now we're stuck with it.  Unfortunately 
we're also stuck with Windows due to this bug.  Hopefully 
IBM's jdk1.4 will come out soon and save us...

Linking against the older libraries is NOT unreasonable on
Sun's part.  For a SIGNIFICANT PORTION of the situations
where you deploy Java on Linux, namely webapps (Servlets,
JSP), you want to securely lock down the host.  That usually
means running an older kernel version, with all the patches
applied, and consequently, an older distro with older libraries.

As pointed out in discussions on www.javalobby.org, it IS
possible to install the older libraries.  On the other hand,
it is also possible for Sun to statically link the JVM and
avoid the problem, as they do at Blackdown, for some cost in
download size.

Check out hints.linuxfromscratch.org

They have a hint (Java from scratch) on how to build the 
JDK from the source so it works on your gcc 3.x system. 

huanghui1,

Thanks for your response. This bug is causing problems for
the Gentoo Linux distribution. Many Gentoo users are already
using gcc3.1 profiles. They experience this bug first hand.
Typically it manifests as Java applets failing to load even
though the user believes the plugin was installed properly.
Not a good show for Java in general.

I'd like to see a gcc3.1 build as soon as possible -- in
1.4.1 would be perfect. If it's a big deal, I don't see why
builds for both gcc2.95.3 AND gcc3.1 can't be made available.

Please make 1.4.1 the release that supports gcc3.x.  It is
desperately needed and will also help with the transition. 
Please don't wait for the transition to happen first, you
will just cause it to take longer.  Thank you for all the
work you've done so far...

Just add me to the list... OpenOffice doesn't work because it 
depends on Java.   Gentoo Linux 1.3 is *Fast* and I hope to 
ditch MS altogether... 

Ahem. Why use binaries with a source distribution when you 
can compile your own? 
http://hints.linuxfromscratch.org/hints/javafromscratch.txt

Of course, you're going to have to borrow a 
libstdc++-libc6.1-1.so.2 to bootstrap it, but it's worth the 
effort.

_2Mike, That's not really an option. The licensing
conditions for that from source Java are so restrictive, it
prevents you from working on certain free software java
projects (such as gnu classpath, kaffe, openjit etc.). Plus
there are other restrictions on it's use. That's why this
bug is so important -- there are no work arounds.

aside from your assumption on what freedoms a user is
willing to give up when building from scratch, you miss the
point entirely. it is a difference between the c++ abi in
gcc 2.95.x (which was used to compile sun-jdk-1.4.0_01) and
the c++ abi in gcc 3.1 which is the problem. as a result the
java plug in and any other c++-based jni application (afaik)
will not run. email me direct if you're still unclear (i
don't wish to turn a bug into a debate)

That restrictive? I doubt it. Besides, are you going to be 
working on clean-room java clones? If you are, it may be a 
problem. I'm not a lawyer. Chances are, most people aren't 
working on java clones. The big problem with licensing is just 
that you can't distribute your binaries, but no one says you 
can't use them. This compile-from-source solution is just fine 
for those gentoo users looking to run jEdit 4.0.x, or any other 
Java 1.4 program. I didn't say it's the solution to your 
multi-million dollar project. If you happen to have one of them 
(good luck!), just distribute 
libstdc++-libc6.1-1.so.2 with the product until statically 
linked binaries are available.

Hmm.. I think I misinterpreted your comments as applying to 
the made-from-source java. If you are talking about the 
binaries + old libstdc, yes, the java plugin won't work. At 
least, not without a workaround found at 
http://hints.linuxfromscratch.org/hints/mozilla.txt or 
http://bugzilla.mozilla.org/show_bug.cgi?id=124006 . People 
will probably want this workaround anyway so they can have 
their flash plugin. JNI will probably still need recompiling, 
although I suspect the workaround used for mozilla *might* 
work. (probably not)

I'm fairly sure I can't email you without an email address, so 
I'll respond here.

A source compile _includes_ the java plugin, so it will work, 
provided you compiled your browser with the proper gcc too. 
Also, if you're willing to compile the jdk, there should be less 
of a problem recompiling a program that uses the JNI. After 
all, if the program used the old ABI, it can't run at all on your 
system, much less with JNI.

I'm curious. What am I missing about the rights taken away 
when agreeing to the license?

What I don't understand is why there needs to be a
transition at all.  The consumers of Java are developers,
and as such, should be capable of choosing between
/multiple/ builds, finding the one which is applicable to
their platform/compiler.
I think JDK point releases should really be /somewhat/
independent of compiler releases - if a new compiler comes
out such as GCC 3, why not at least release an "unstable,
untested, developer" build for that compiler?
That said, the current stable release, GCC 3.1.1, has known
ABI bugs causing generated binaries not to comply with the
multi-vendor ABI standard.  The GCC folks are patching ONLY
these few bugs for the next stable release, which, since
they are changing binary compatibility, will be called GCC
3.2 - whose release is scheduled immediately.
Building with 3.1.1 doesn't make any sense, in that binary
compatibility will break again immediately with 3.2.  And
with 3.2 we will hopefully be ensured compatibility for a
long time to come.  And 3.2 is basically just 3.1.1 with
ABI, and 3.1.1 probably wouldn't have even been released if
it wasnt for Apple wanting it for Jaguar.

So, yeah, I vote for a 2.95 AND 3.2 release of Java 4.1.

gcc 3.2 was officially released on August 14.

The 2.95 -> 3.0x -> 3.1x -> 3.2 C++ ABI transitions were
painful, but 3.2 is supposed to be the stable ABI for a
while.  Linux will make the final transition from gcc 2.95
to 3.2 *quickly* to break out of this ugly transition period
and stabilize on the new ABI.  

(Back in the gcc 3.0 beta days RedHat caught a lot of flack
for adopting the new compiler too quickly.  This time SuSE
and Mandrake are already out in front of RedHat, so when
RedHat 8.0 is released with gcc 3.2, most of the commercial
Linux market will be there.  Java needs to be ready.  Note
that the "Limbo" RedHat 8.0 beta is already available, so
this is absolutely happening in the j2sdk 1.4.1 timeframe. 
You cannot safely put it off to 1.4.2.)

Recommendations:

1. Be absolutely certain that the same j2sdk 1.4.1 source
code compiles cleanly under all gcc versions from 2.95 to
3.2.  If necessary, #ifdefs are way better than patches. 
(Patches are necessary to compile the j2sdk 1.4.0 code under
gcc 3.2.)

2. Compile j2sdk 1.4.1 statically to insulate from
underlying shared library issues.  This is especially key
for the Java Plug-In and JRE, which need to be run by less
technical people.  Granted, this will bloat the download
size, but better a bigger download that works for everyone
than a smaller one that doesn't.  (BTW if you want to reduce
the bloat, switch from gzip to bzip2 for the tarball
packages at the same time.  bzip2 support is now universal
in Linux so this is a no-brainer, not a risk.)

By the j2sdk 1.4.2 release date, gcc 3.2 should be
widespread enough to go back to dynamic compilation and
smaller downloads.  But during this transition period I
think it's too dangerous.  Your choices are static
compilation or multiple versions.  Choosing to ignore the
issue and only support outdated gcc versions will cause a
lot of needless flack to be thrown at Sun from the Linux
community.  (This is the tip of the iceberg -- once RedHat
8.0 is released, anything that doesn't support gcc 3.2 will
appear antediluvian.)

My work-around for this problem was to create a symlink to 
libstdc++.so.4.0.0 called libstdc++-libc6.1-1.so.2 and re-run 
the RPM.

I agree with the latest posts requesting a 1.4.1 release for
GCC 2.95.x and GCC 3.2.  Releasing a GCC 3.0, GCC 3.1, or
GCC 3.1.1 version should not be necessary as these are all
different ABI's and are already outdated.  Furthermore,
since the 3.2 ABI should remain stable, the transition will
need to occur eventually.  (I for one am ready to move
beyond GCC 2.95.3.)

If Sun only provides two versions, users should not be
overly frightened--especially if explicit instructions for
determining GCC version are provided (i.e. "Type 'gcc
--version' into a shell").  I would even be appeased if the
GCC 3.2 compatible version were "hidden" on the web site
such that most users just download the GCC 2.95.x compatible
version.

huanghui1,

Thanks for asking! The Mozilla maintainer for Mandrake would
have STRONGLY preferred to compile Mozilla (and Enigmail)
with GCC 3.x for the upcoming Mandrake 9.0 release. Mozilla
Source code, unlike the JDK/JRE source, is GPL. Mandrake
(and anyone else) is therefore free to create and DISTRIBUTE
2.x or 3.x binaries. Nearly everything else in Mandrake 9.9
is compiled with GCC 3.x. The Sun JDK/JRE license does not
allow for such a redistribution (you may compile only for
private use). The problem is here, not with Mozilla. I
strongly agree (with mtdean) that any Linux person is
capable of choosing the correct JDK/JRE Linux binary with a
couple of hints. It's only slightly harder than choosing
between the 'Linux' and 'Solaris' downloads. Please provide
alternate versions for GCC 2.95 and GCC 3.x (latest
production/stable version).

Yeah.  What Galdor said.

This really needs to be fixed. I can't write my programming
assignments for class because of this. I'm using gcc 3.2.

Remember that all sane distros will ship compat libraries
that has this libstdc++ version. If not, yell loudly at your
distro makers.
Secondly gcc 3.1 and libstdc++ v 4 should not be considered,
its old.
gcc 3.2 comes with v5.0, and although it almost promised to
keep the ABI, several flaws have been found. What they will
do in gcc 3.3 noone knows yet.

I have code that runs ok on Windows.  I compiled it on
RedHat Linux 7.2 using gcc-2.96 and the VM aborts when an
exception is thrown in JNI.  I compiled with gcc-2.95-3 and
I get a segmentation fault instead of an abort.  Do I need
to go back to JDK 1.3.1? Do I need to use a different
compiler?  What combination of compiler/library/whatnot is
known to work on Linux?

This is a real upset, and puts a lot of people into a sticky  
situation, including myself.  
Well, untill Java works again I'll just grab Mono and learn  
.net. 

This is a HUGE problem.  I'm running Redhat 8.0 and can't
view java applets because redhat uses gcc 3.2.  So, right
now I'm steering clear of java software.  Considering the
market share Redhat has, I'd say this is a major problem for
Sun.  Most windows users are NOT going to install sun
java...they will install Microsoft's java vm...and this is
probably a big jab at the heart of the community that will
actually install java and develop using it.

vote for 1.4.1 (aka as soon as possible)

  After SuSE 8.1 and RedHat 8.0 were released, a lot of the 
management consoles that are web-based refused to work 
on our systems due to the gcc problem. However, wether 
Sun releases a statically linked binary or different release 
really depends on whether they want to support 2 versions 
for Linux, or have a bigger download. It doesn't matter for 
me either way, but I hate using RDesktop to get to Java 
Applet pages for management of ciritical functions a my 
company.

Here are what we plan to do to solve the libstdc++ problem:

1. statically link libstdc++ (4706607), remove dependency on
libstdc++-libc6.1-1.so.2
2. limit dynamic symbols (4776723), avoid symbol conflicts
between the libstdc++ linked with VM and the (potentially
different version) libstdc++ linked with JNI library.

There is also another problem related to the different
versions of GCC,
and that is the mangled names of virtual classes.
For example the class nsGetServiceByCID is mangled
__vt_17nsGetServiceByCID by GCC 2.x but _ZTV17nsGetServiceByCID
by GCC 3.x.
This makes it impossible to use the java plugin
libjavaplugin_oji.so
in a Mozilla compiled with GCC 3.2 since the plugin is
compiled with
GCC 2.x.
This leaves all our students (+2000) without a functional
JVM for
their webbrowser. (We also have Netscape Communicator 4.8, but
that one keeps on craching)

Slackware 9.0 will be built using gcc 3.2.1 too 

TO esquille:

The Java plugin code has already been changed for the
upcoming 1.4.2 - it no longer needs mangled C++ symbols.

Every system that makes use of the newer gcc produces
problems with the old-style linked JDK.

JDK (that means: Sun) seems to block all newer OS developments.

Sep, Oct, Nov, Dec, Jan, Feb. This bug is now in 4th place
on the voting list. Sun should release alternate Linux 1.4.1
JDK/JRE versions for use in systems which are built entirely
with gcc-3.2.

This bug shows no status change since November 27.
Developers are not going to abandon GCC and GNU/Linux. If
you don't resolve this problem, many of us will abandon the
Sun JDK and JRE instead. 

FYI: the Blackdown project has recently released the 1.4.1
JDK build for Linux, using libstdc++.so.5 as comes with GCC
3.2. You can download it at
http://www.blackdown.org/java-linux.html
Works like a charm for me.

Hopefully Sun will follow soon.

On the 1.4.1_02 download site
http://java.sun.com/j2se/1.4.1/download.html
Installation Notes/Linux, you say
"This version of the JavaTM 2 Runtime Environment (Java RE)
is supported on Intel Pentium platforms running the Linux
kernel v 2.2.12 and glibc v2.1.2-11 or later."

So have you fixed it? Then why is this bug "In progrss"? If
you haven't fixed it, why are you still lying about
requirements?

The bug is still "in progress" because there have been
issues with
Java plugin (4687814). This bug is supposed to track gcc
compatibility
issues, I won't close this one until 4687814 is fixed, which
should happen
in 1.4.2-beta.

OK, 4687814 is now marked as being "Closed, fixed".
Release Fixed  mantis-beta, tiger