Updates on the "moving" symbols problem:
The problem with gdb not finding out the type of tzname[] is caused by
the shared libs not being built with -g. It probably doesn't have to
do with the problem.
I appended a tarfile with some test cases. Case 1-3 show different
occasions of the error, all dump core when linked dynamically and work
fine with -static. 'shlib3.gdb' fed into gdb will show that the symbol
address is a moving target.
Case 4 is an attempt to reproduce the error I get with tzname[] from
libc.so with a newly constructed shared library and a similar symbol.
However, this case works fine and I don't understand the difference so
far. Set LD_LIBRARY_PATH=`pwd` to run this test case.
I have updated two machines to -current from yesterday, no change in
the problem. As I suspect the MMU hardwware may influence the problem,
here are the CPU ids from the machine I can reproduce the error on
(that doesn't mean I have -current machines where the error does not
show up):
CPU: Pentium Pro (199.31-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x619 Stepping = 9
Features=0xf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV>
CPU: Pentium/P54C (99.95-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52c Stepping = 12
Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
Let me repeat that this looks like a serious memory mapping bug and
that we must not ship 4.0 until we gain more knowledge about it.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
shlib.tar.gz
