public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would  that even help?)
@ 2009-10-30 14:01 Duncan Smith
  2009-10-30 15:24 ` Albert Hopkins
  2009-10-30 21:52 ` Kyle Bader
  0 siblings, 2 replies; 11+ messages in thread
From: Duncan Smith @ 2009-10-30 14:01 UTC (permalink / raw
  To: gentoo-user

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)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would  that even help?)
  2009-10-30 14:01 [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?) Duncan Smith
@ 2009-10-30 15:24 ` Albert Hopkins
  2009-10-30 15:26   ` Volker Armin Hemmann
  2009-10-30 21:52 ` Kyle Bader
  1 sibling, 1 reply; 11+ messages in thread
From: Albert Hopkins @ 2009-10-30 15:24 UTC (permalink / raw
  To: gentoo-user

On Fri, 2009-10-30 at 10:01 -0400, Duncan Smith 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?

You are just just as likely to get support from Gentoo about software we
have no access to as your distributer is to support Gentoo.
 
>  2. Any idea what's going on?  Could it be something other than glibc
> causing the problem?

It could be one of a hundred million things.  Without access to the
program it's really hard to tell.

>  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 ;)

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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would  that even help?)
  2009-10-30 15:24 ` Albert Hopkins
@ 2009-10-30 15:26   ` Volker Armin Hemmann
  2009-10-30 19:22     ` Duncan Smith
  0 siblings, 1 reply; 11+ messages in thread
From: Volker Armin Hemmann @ 2009-10-30 15:26 UTC (permalink / raw
  To: gentoo-user

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-30 15:26   ` Volker Armin Hemmann
@ 2009-10-30 19:22     ` Duncan Smith
  2009-10-30 19:37       ` Volker Armin Hemmann
  0 siblings, 1 reply; 11+ messages in thread
From: Duncan Smith @ 2009-10-30 19:22 UTC (permalink / raw
  To: gentoo-user

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.
>
>



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?)
  2009-10-30 19:22     ` Duncan Smith
@ 2009-10-30 19:37       ` Volker Armin Hemmann
  2009-11-02 18:45         ` Duncan Smith
  0 siblings, 1 reply; 11+ messages in thread
From: Volker Armin Hemmann @ 2009-10-30 19:37 UTC (permalink / raw
  To: gentoo-user

On Freitag 30 Oktober 2009, Duncan Smith wrote:
> 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.

chroot can work nicely, but you have to create a gentoo with a very old glibc. 
The problems might not be worth it.

Virtualbox on the other hand is pretty much hassle free in my experience. 
Can't talk about vmware - haven't used that in years ;)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-30 14:01 [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?) Duncan Smith
  2009-10-30 15:24 ` Albert Hopkins
@ 2009-10-30 21:52 ` Kyle Bader
  2009-10-30 21:58   ` Alan McKinnon
  2009-10-30 23:27   ` Albert Hopkins
  1 sibling, 2 replies; 11+ messages in thread
From: Kyle Bader @ 2009-10-30 21:52 UTC (permalink / raw
  To: gentoo-user

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?)
  2009-10-30 21:52 ` Kyle Bader
@ 2009-10-30 21:58   ` Alan McKinnon
  2009-10-30 23:27   ` Albert Hopkins
  1 sibling, 0 replies; 11+ messages in thread
From: Alan McKinnon @ 2009-10-30 21:58 UTC (permalink / raw
  To: gentoo-user

On Friday 30 October 2009 23:52:10 Kyle Bader wrote:
> 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 :)


If it's a somewhat critical machine for business, just drop a new stand-alone 
box running RHEL4. Critical machines usually generate|save more cash than the 
cost of the box they run on








> 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)
> 

-- 
alan dot mckinnon at gmail dot com



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-30 21:52 ` Kyle Bader
  2009-10-30 21:58   ` Alan McKinnon
@ 2009-10-30 23:27   ` Albert Hopkins
  2009-10-31  9:20     ` William Kenworthy
  1 sibling, 1 reply; 11+ messages in thread
From: Albert Hopkins @ 2009-10-30 23:27 UTC (permalink / raw
  To: gentoo-user

On Fri, 2009-10-30 at 14:52 -0700, Kyle Bader wrote:
> I dunno how
> flexible the vendor is but its worth asking :) 

They only support RHEL4. RHEL4 was released nearly 5 years ago and uses
the 2.6.9 kernel.  I think that shows how flexible they are. :)





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-30 23:27   ` Albert Hopkins
@ 2009-10-31  9:20     ` William Kenworthy
  2009-11-02 18:52       ` Duncan Smith
  0 siblings, 1 reply; 11+ messages in thread
From: William Kenworthy @ 2009-10-31  9:20 UTC (permalink / raw
  To: gentoo-user

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





On Fri, 2009-10-30 at 19:27 -0400, Albert Hopkins wrote:
> On Fri, 2009-10-30 at 14:52 -0700, Kyle Bader wrote:
> > I dunno how
> > flexible the vendor is but its worth asking :) 
> 
> They only support RHEL4. RHEL4 was released nearly 5 years ago and uses
> the 2.6.9 kernel.  I think that shows how flexible they are. :)
> 
> 
> 
-- 
William Kenworthy <billk@iinet.net.au>
Home in Perth!




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-30 19:37       ` Volker Armin Hemmann
@ 2009-11-02 18:45         ` Duncan Smith
  0 siblings, 0 replies; 11+ messages in thread
From: Duncan Smith @ 2009-11-02 18:45 UTC (permalink / raw
  To: gentoo-user

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-user] Installing an old glibc to run a proprietary  commercial tool (would that even help?)
  2009-10-31  9:20     ` William Kenworthy
@ 2009-11-02 18:52       ` Duncan Smith
  0 siblings, 0 replies; 11+ messages in thread
From: Duncan Smith @ 2009-11-02 18:52 UTC (permalink / raw
  To: gentoo-user

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2009-11-02 18:52 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-30 14:01 [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?) Duncan Smith
2009-10-30 15:24 ` Albert Hopkins
2009-10-30 15:26   ` Volker Armin Hemmann
2009-10-30 19:22     ` Duncan Smith
2009-10-30 19:37       ` Volker Armin Hemmann
2009-11-02 18:45         ` Duncan Smith
2009-10-30 21:52 ` Kyle Bader
2009-10-30 21:58   ` Alan McKinnon
2009-10-30 23:27   ` Albert Hopkins
2009-10-31  9:20     ` William Kenworthy
2009-11-02 18:52       ` Duncan Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox