Very Computer

From the glibc FAQ:

Quote:> 2.27.      What needs to be recompiled when upgrading from glibc 2.0 to glibc
>    2.1?

> {AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
> that have been linked against glibc 2.0 will continue to work.

        /usr2.0/lib/libc.so.6:0001b648 T __setfpucw
        /usr2.1/lib/libc.so.6:0001d2c8 t __setfpucw

The latest jdk1.2 was compiled for glibc2.0 but doesn't run with glibc2.1,
yielding the following inscrutable error.

    geometry% java
    *** panic: GC: getStickySystemClass failed: java/lang/ref/Reference
            CLASSPATH may be incorrect

and some more output.  I can't figure out why.

Applications that are linked also against libstdc++.so.2.8 seem to break -
perhaps due to the lowlevel IO routines that are shared, or a change to what
a FILE is.

Have other people had experience with this sort of thing?

Would this behavior be regarded as a bug by the developers of glibc-2.1, so
that we can look forward to fixes?

Quote:>>>>> Daniel R Grayson writes:

Quote:>> 2.27.  What needs to be recompiled when upgrading from glibc 2.0 to glibc
>> 2.1?

>> {AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
>> that have been linked against glibc 2.0 will continue to work.

Daniel> The statement above doesn't seem to be true.  For example, my emacs-20.3.3
Daniel> broke because a symbol called __setfpucw became internal.

Daniel>      /usr2.0/lib/libc.so.6:0001b648 T __setfpucw
Daniel>      /usr2.1/lib/libc.so.6:0001d2c8 t __setfpucw

Daniel> The latest jdk1.2 was compiled for glibc2.0 but doesn't run with glibc2.1,
Daniel> yielding the following inscrutable error.

Did you read the README files that come with the *pre*release of jdk
1.2?  It mentions that jdk is only tested on 2.0 and you've got to
pass the following parameters: "-green -Djava.compiler=" to get it
working (but they explicitly state that they're planning to do a glibc
2.1 release).

Daniel>     geometry% java
Daniel>     *** panic: GC: getStickySystemClass failed: java/lang/ref/Reference
Daniel>          CLASSPATH may be incorrect

Daniel> and some more output.  I can't figure out why.

Daniel> Applications that are linked also against libstdc++.so.2.8 seem to break -
Daniel> perhaps due to the lowlevel IO routines that are shared, or a change to what
Daniel> a FILE is.
Read again FAQ 2.21.   "What do I need for C++ development?" and
recompile libstdc++.

Daniel> Have other people had experience with this sort of thing?

Daniel> Would this behavior be regarded as a bug by the developers of glibc-2.1, so
Daniel> that we can look forward to fixes?
Nothing you reported counts as a glibc bug.

Andreas
--

Thank you for the helpful advice, including the java workaround.  I now know
what to do with libstdc++.so.2.8.

Perhaps the FAQ could be modified to read something like this:

    2.27.       What needs to be recompiled when upgrading from glibc 2.0 to glibc 2.1?

    {AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
    that have been linked against glibc 2.0 will continue to work, unless they
    incorrectly use symbols intended to be private, such as __setfpucw (see 3.12 below).