Re: [gentoo-user] Changing glibc

2014-08-20 Thread Mick
On Monday 18 Aug 2014 20:56:53 Timur Aydin wrote:
 Thanks a lot guys for the helpful responses. I will definitely try all
 of them, just for the learning experience, even if one does take care of
 the problem.
 
 Cheers!

Also worth looking into is meld, if you are not running kde on your system.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


[gentoo-user] Changing glibc

2014-08-18 Thread Timur Aydin

Hi,

I am using a closed source software package on my 64 bit gentoo linux 
system. The software package is beyond compare by scooter soft. 
Because of the way this package is built, it needs a specially patched 
version of glibc. I have patched my existing glibc version (2.18) and 
have been avoiding updating my glibc since. Now I am wondering whether 
the latest update of bcompare will work with the latest glibc (2.19).


So, if I upgrade to 2.19 and the package doesn't work, how can I go back 
to the working, patched 2.18? I know that portage issues the most scary 
warnings when you try to downgrade glibc. So what does the community 
recommend?


--
Timur



Re: [gentoo-user] Changing glibc

2014-08-18 Thread Manuel McLure
One option is to copy the glibc version you want to some other directory
and set LD_LIBRARY_PATH before starting the executable. Running ldd on
all the executables/shared libraries in question should give you a list of
all the shared libraries you might need to copy to a safe place.


On Mon, Aug 18, 2014 at 11:06 AM, Timur Aydin t...@taydin.org wrote:

 Hi,

 I am using a closed source software package on my 64 bit gentoo linux
 system. The software package is beyond compare by scooter soft. Because
 of the way this package is built, it needs a specially patched version of
 glibc. I have patched my existing glibc version (2.18) and have been
 avoiding updating my glibc since. Now I am wondering whether the latest
 update of bcompare will work with the latest glibc (2.19).

 So, if I upgrade to 2.19 and the package doesn't work, how can I go back
 to the working, patched 2.18? I know that portage issues the most scary
 warnings when you try to downgrade glibc. So what does the community
 recommend?

 --
 Timur




-- 
Manuel A. McLure WW1FA man...@mclure.org http://www.mclure.org
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft


Re: [gentoo-user] Changing glibc

2014-08-18 Thread Kerin Millar

On 18/08/2014 19:06, Timur Aydin wrote:

Hi,

I am using a closed source software package on my 64 bit gentoo linux
system. The software package is beyond compare by scooter soft.
Because of the way this package is built, it needs a specially patched
version of glibc. I have patched my existing glibc version (2.18) and
have been avoiding updating my glibc since. Now I am wondering whether
the latest update of bcompare will work with the latest glibc (2.19).

So, if I upgrade to 2.19 and the package doesn't work, how can I go back
to the working, patched 2.18? I know that portage issues the most scary
warnings when you try to downgrade glibc. So what does the community
recommend?



You should be able to downgrade glibc, provided that you haven't built 
and installed any new packages following the transition from glibc-2.18 
to glibc-2.19. That said, I would suggest that you back up the root 
filesystem as a contingency measure.


Still, why not test bcompare in a chroot? The latest stage3 tarball 
probably includes glibc-2.19 by now.


--Kerin



Re: [gentoo-user] Changing glibc

2014-08-18 Thread J. Roeleveld
On 18 August 2014 20:06:51 CEST, Timur Aydin t...@taydin.org wrote:
Hi,

I am using a closed source software package on my 64 bit gentoo linux 
system. The software package is beyond compare by scooter soft. 
Because of the way this package is built, it needs a specially patched 
version of glibc. I have patched my existing glibc version (2.18) and 
have been avoiding updating my glibc since. Now I am wondering whether 
the latest update of bcompare will work with the latest glibc (2.19).

So, if I upgrade to 2.19 and the package doesn't work, how can I go
back 
to the working, patched 2.18? I know that portage issues the most scary

warnings when you try to downgrade glibc. So what does the community 
recommend?

In cases like that I would do either of the following:

1) Run it inside a VM
2) run it inside a chroot

That way you can easily keep everything updated except for that application.

--
Joost

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-user] Changing glibc

2014-08-18 Thread Rich Freeman
On Mon, Aug 18, 2014 at 2:21 PM, J. Roeleveld jo...@antarean.org wrote:

 In cases like that I would do either of the following:

 1) Run it inside a VM
 2) run it inside a chroot

 That way you can easily keep everything updated except for that application.

Or better still run it inside a container.  Gives you most of the
benefits of both a VM and a chroot.  It isn't as isolated as a VM, but
it is more isolated than just running the thing on your system.  It is
also easy to bind-mount your home directory if that is helpful.  A
container replaces the entire userspace, potentially including init as
well.  So, as long as your kernel is compatible and you're not doing
anything too crazy with devices, this should solve your compatibility
issues.

--
Rich



Re: [gentoo-user] Changing glibc

2014-08-18 Thread Timur Aydin
Thanks a lot guys for the helpful responses. I will definitely try all 
of them, just for the learning experience, even if one does take care of 
the problem.


Cheers!

--
Timur



Re: [gentoo-user] Changing glibc

2014-08-18 Thread J. Roeleveld
On Monday, August 18, 2014 03:12:15 PM Rich Freeman wrote:
 On Mon, Aug 18, 2014 at 2:21 PM, J. Roeleveld jo...@antarean.org wrote:
  In cases like that I would do either of the following:
  
  1) Run it inside a VM
  2) run it inside a chroot
  
  That way you can easily keep everything updated except for that
  application.
 Or better still run it inside a container.  Gives you most of the
 benefits of both a VM and a chroot.  It isn't as isolated as a VM, but
 it is more isolated than just running the thing on your system.  It is
 also easy to bind-mount your home directory if that is helpful.  A
 container replaces the entire userspace, potentially including init as
 well.  So, as long as your kernel is compatible and you're not doing
 anything too crazy with devices, this should solve your compatibility
 issues.

I should look into those.
Just noticed there is also a libvirt driver for it:
http://libvirt.org/drvlxc.html



 --
 Rich