Re: [linuxsh-dev] glibc-2.2

[M. R. B. <ma...@uw...>]

On Tue, 6 Mar 2001, Denis Dowling wrote:

> "M. R. Brown" wrote:
> > 
> > I've built glibc-2.2 via the instructions on the LinuxSH page, and by
> > patching the requisite files (I used Niibe's debian patches as a guide).
> > The build process is smooth, no problems there.  However, when I boot
> > using the newly-installed libraries and dynamic linker, I get segmentation
> > faults everytime I run a dynamically-linked program.  I'm able to boot my
> > system using a statically-linked bash.
> > 
> > Just to test, I substituted Niibe's debian glibc-2.2 (from base), and
> > dynamically-linked programs worked perfectly.  I'm guessing it's a problem
> > buried in libc, because just swapping out ld-linux.so.2 ran the program,
> > but my system soon ran out of memory within libc.
> > 
> > So I'm curious, is there another build method for glibc (like which one
> > did you use Niibe?).  Oh yeah, I'm using a gcc as of yesterday :), maybe
> > my gcc is just broken?
> 
> This could be a gcc problem. I am having problems with shared libraries
> in the latest gcc 3.0 branch. Shared libraries appear to work fine with
> gcc 2.97 (20001120).
>

Ok, I've built glibc-2.2 with gcc-20001120 and still no-go.  This time
around, instead of a segfault I'm just getting "out of memory" errors from
the kernel.  Like I said, statically-linked programs are fine, so now it's
a problem with ld-2.2.so or my build process (or glibc target which is
sh4), because the glibc from NIIBE's distro works fine, and now I'm using
the same compiler and patches... 

Just to test, I have a static ls as "ls" and a dynamically-linked ls as
"dynls":

[from dmesg output]
Memory: 10700k/16384k available (1011k kernel code, 5684k reserved, 52k
data, 52k init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)

[...]

block: queued sectors max/low 7000kB/2333kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 4096k freed

[...]

Freeing unused kernel memory: 52k freed
 init-2.03# 
init-2.03# ls
bin  dev  lib
init-2.03# dynls
Out of Memory: Killed process 8 (dynls).
Terminated

Has anyone come across this or am I missing something obvious :)?

M. R.