current recommended versions of glibc/egcs/binutils for R5?

What are the currently recommended *stable* versions of glibc, egcs
and binutils in R5?  Should I stick with the installed versions:

 glibc 2.1.1-6c, egcs 1.1.2-12c, binutils 2.9.1.0.990418-1c

or use the newer versions available on linuxppc.org:

 glibc 2.1.2-1a, egcs 1.1.2-12f, binutils-2.9.4.0.8-1a

or some other versions?  I'm looking for stability here, not the
latest experimental releases.



-- 
reshapiro@mediaone.net
rshapiro@bbn.com

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Am Son, 01 Aug 1999 schrieb R Shapiro:

What are the currently recommended *stable* versions of glibc, egcs
and binutils in R5?  Should I stick with the installed versions:

glibc 2.1.1-6c, egcs 1.1.2-12c, binutils 2.9.1.0.990418-1c

or use the newer versions available on linuxppc.org:

glibc 2.1.2-1a, egcs 1.1.2-12f, binutils-2.9.4.0.8-1a

I consider the newer versions stable and told the distribution maintainers
about it.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Hey,

Does anyone know what's up with gdb lately?  It used to be quite stable but
since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
can't seem to set any breakpoints in shared libraries (or they show up
someplace else at random).  Functions are missing (or don't show up) and if
I try to disassemble one function in a shared library, I often get another.

I really need a working stable gdb.

Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
binutils, egcs are stable together, especially when working with shared
libraries?

Thanks,

Kevin




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Am Son, 01 Aug 1999 schrieb Kevin B. Hendricks:

Hey,

Does anyone know what's up with gdb lately?  It used to be quite stable but
since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
can't seem to set any breakpoints in shared libraries (or they show up
someplace else at random).  Functions are missing (or don't show up) and if
I try to disassemble one function in a shared library, I often get another.

I really need a working stable gdb.

Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
binutils, egcs are stable together, especially when working with shared
libraries?

Well, you've hit one of our weakest points here. AFAIK there's currently nobody
taking care of gdb on Linux/PPC. In fact we are lucky that Kevin Buettner's old
patch could be converted to 4.17.x. Unfortunately it's still not integrated
into gdb's mainline due to copyright issues, so we have to reintegrate the patch
in every new version :-(.

So, is someone willing to take care of gdb on Linux/PPC?

Kevin, as a first measure, do you pass LD_BIND_NOW=1 in the environment?

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

On Sun, 01 Aug 1999, Franz Sirl wrote:

Kevin, as a first measure, do you pass LD_BIND_NOW=1 in the environment?

Franz.

Yes, that is the default we set with the jdk.  Unfortunately it is no help.
Could this be kernel related?  I saw this problem with some of Paul's kernels
under R4 and then all problems with gdb went away.  Everything worked fine
under YDL but since my upgrade to LinuxPPC R5 and Paul's 2.2.10 kernel, the old
problems have re-appeared.

It is like some piece of cache is not being properly flushed.

By the way, I noticed from disassembling some code from egcs 1.1.2-12c that the
stwu instruction is being used again.  I thought Gary Thomas patched the egcs
source to prevent stwu from being generated becuase of some serious problems
with it being used in certain combinations on 604e systems.  Any info on this?

Thanks,

Kevin

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Hi,

Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads? 

If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
sem_post@@GLIBC_2.0, etc, they work fine. 

If I link the native threads version of the jdk with the new semaphore
functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.

I found this out because I had two binariies from the same source, one of which
works and the other doesn't and the only difference was that the first (working
one) was built under an earlier glibc 2.1 while the latter was built with
Franz's latest glibc 2.1.2.

Upon further investigation with nm I found  that the only difference was in
which semaphore functions got linked in from libpthread.so.

If it matters, this is in a high signal environment (thread interrupts, thread
suspension for garabage collection, etc).

I had to drop back to glibc 2.1.1 and rebuild to get the
native_threads to start working again (so that they would link with the old
sem_* functions and not the new).

Has anyone really tested the new semaphore functions?  Are they known to be
broken?  

Any ideas here?

Thanks,

Kevin


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Am Son, 22 Aug 1999 schrieb Kevin Hendricks:

Hi,

Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads? 

If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
sem_post@@GLIBC_2.0, etc, they work fine. 

If I link the native threads version of the jdk with the new semaphore
functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.

I found this out because I had two binariies from the same source, one of which
works and the other doesn't and the only difference was that the first (working
one) was built under an earlier glibc 2.1 while the latter was built with
Franz's latest glibc 2.1.2.

Upon further investigation with nm I found  that the only difference was in
which semaphore functions got linked in from libpthread.so.

If it matters, this is in a high signal environment (thread interrupts, thread
suspension for garabage collection, etc).

I had to drop back to glibc 2.1.1 and rebuild to get the
native_threads to start working again (so that they would link with the old
sem_* functions and not the new).

Has anyone really tested the new semaphore functions?  Are they known to be
broken?  

Any ideas here?

Kevin, the glibc-2.1.2 RPM's are work-in-progress. They generally work well for
me and others, but it may very well be that things are temporarily broken.
Please test the new 4a build. If your problem persists I'll forward it to the
glibc maintainers.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]