On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote: > FUD or just plain stupid. He could have solved all the problems he > described by just simply linking statically his proggie. Well, yes, though there may be some reason it must be dynamically linked. "Marvin" == Marvin Justice <mjustice@austin.rr.com> writes: >> Anyway, I just wanted to let you know that there are some glibc issues that >> are more restrictive than the kernel issues. On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote: > FUD. Period. On my system mozilla's (as an example of shlib heavy app) > shared libraries occupy (with holes) 0x40000000-0x417bc000 == > 0x17bc000 == 24887296 ~= 23.7 MB. What's the problem allocating > libraries at e.g. 0x8000000? Or 0xa0000000? Actually, it's an interaction with the kernel. The ELF .interp is loaded by default at 0x40000000 when formatted as a DSO. Formatting the .interp as a statically linked executable will allow you to specify the placement in memory (at least in an advisory way) of your runtime linker, if you care to implement a runtime linker or adjust glibc's. Alternatively, you could have the .interp literally copy itself out of the way and perform relocation processing on itself a second time. At any rate, probably the core issues here are (as I see them) (1) glibc's allocator is unable to deal with a process address space fragmented by ld.so sitting up at 0x40000000 (2) the kernel makes a default placement decision for the .interp that fragments the process address space Either of these things can be customized to prevent the problem by itself, though (2) is likely to raise as many issues as it solves. Cheers, Bill -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
