1 |
The company I work for is using gentoo on all its machines. We just |
2 |
got a license to a commercial tool which does not support gentoo. The |
3 |
closest thing it supports is RHEL v4. |
4 |
|
5 |
Running any command provided by the tool results in an explosive |
6 |
memory leak (virtual memory hits 400G in 1 second, and continues to |
7 |
climb). |
8 |
|
9 |
I suspect the problem is that RHEL v4 uses =sys-libs/glibc-2.3.4, |
10 |
whereas we have =sys-libs/glibc-2.9_p20081201-r2 installed. |
11 |
|
12 |
I have three questions: |
13 |
1. Am I posting to the right list? |
14 |
2. Any idea what's going on? Could it be something other than glibc |
15 |
causing the problem? |
16 |
3. If it is glibc, is there some way to install glibc slotted? Could |
17 |
I install an old version of glibc to some other lib folder (like |
18 |
/opt/lib64), and then use LD_LIBRARY_PATH somehow to get the tool to |
19 |
look there first? How? |
20 |
|
21 |
Thanks for any help or ideas. |
22 |
|
23 |
Duncan |
24 |
|
25 |
P.S. In case it's useful, here is the output of ldd: |
26 |
linux-vdso.so.1 => (0x00007fff9e3ff000) |
27 |
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f49c871b000) |
28 |
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f49c8503000) |
29 |
libm.so.6 => /lib/libm.so.6 (0x00007f49c827e000) |
30 |
libdl.so.2 => /lib/libdl.so.2 (0x00007f49c807a000) |
31 |
libc.so.6 => /lib/libc.so.6 (0x00007f49c7d07000) |
32 |
/lib64/ld-linux-x86-64.so.2 (0x00007f49c897a000) |