Thank you both for your quick response.

I'll probably end up taking the virtual machine approach. I may also
try some sort of chroot solution... I'll see how much of a hassle
vmware is.

2009/10/30 Volker Armin Hemmann <volkerarmin@googlemail.com>:
> On Freitag 30 Oktober 2009, Albert Hopkins wrote:
>
>> > *3. If it is glibc, is there some way to install glibc slotted? *Could
>> > I install an old version of glibc to some other lib folder (like
>> > /opt/lib64), and then use LD_LIBRARY_PATH somehow to get the tool to
>> > look there first? *How?
>>
>> You can't have multiple versions of glibc. *And you can't downgrade
>> glibc. *Attempting to do so may result in having more than just that
>> program misbehaving
>
> you can have multiple glibc's. Just not via portage.
> But yes, it is a mess. A mess that is most likely to explode violently.
>
>>
>> My suggestion, for your sanity and support: if you insist on Gentoo then
>> at least run RHEL4 (or CentOS or whatever) inside a virtual machine and
>> run your app from there.
>>
>
> yeah, I would go down that route too.
>
>

Avoiding 1, 2, and 3 but thought I'd propose a 4 other than a virtual
machine. Ask the vendor if they can provide a statically compiled
version, that way you don't have to worry about libc. I dunno how
flexible the vendor is but its worth asking

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

--
Sent from my mobile device


Kyle

2009/10/30 Volker Armin Hemmann <volkerarmin@googlemail.com>:
> Virtualbox on the other hand is pretty much hassle free in my experience.
> Can't talk about vmware - haven't used that in years

Thanks for the pointer to Virtualbox... I hadn't heard of it. Looks
like the wiki has some help, though.
http://en.gentoo-wiki.com/wiki/VirtualBox

I'll give it a shot before vmware.

2009/10/31 William Kenworthy <billk@iinet.net.au>:
> I was in a similar position some years ago - grab a copy of the needed
> libs from somewhere and use "ldpreload" to load them into memory before
> running the application. *Google will help.
>
> In some cases, you can symlink the needed lib names to existing later
> libs *and run ldconfig before trying to run the app. *This does work
> sometimes, but success varies ...
>
> BillK

Interesting... I may give that a shot. Should be able to crank out a
wrapper script to do that automatically.

It'd be prudent to have RHEL4 anyway, since that's what some of our
customers are running, but it's good to have another option.