[clug] Virtualisation solution for development

[Ben Nizette]

On 22/06/2011, at 8:34 PM, Duncan Roe wrote:

> Hi Ben,
> 
> I used to run a 64/32 system with really no problem (except the time to keep
> both sets of software up to date). I put 64-bit libraries in /lib64 and
> /usr/lib64, and kept /usr/local all 32-bit (it was --bind mounted from the
> 32-bit partition).
> 
> ld-linux.so has no problem working out whether to load 32-bit or 64-bit .so
> when both exist under their respective directories. Eventually I got lazy and
> reverted to the 32-bit partition for everything. Now Slackware releases
> 64-bit, I might go back to the mixed system (they've done a good job of making
> packages that co-exist).

Cheers Duncan, yeah that's more or less how I survive now.  The problems come about when 3rd parties release badly-written proprietary software, unpackaged, written in something like Tcl/Tk, with fully-qualified, absolute path names specified as arguments to obscure library loaders that bypass ld.so entirely.  Seems to happen when people port software without really understanding how Linux works..  And yea it does happen, all too often :)

Thx,
	--Ben.

> 
> Cheers ... Duncan.
> 
> On Wed, Jun 22, 2011 at 05:16:48PM +1000, Ben Nizette wrote:
>> Hi All,
>> 
>> For the last several months I've been trying to keep 32-bit and 64-bit
>> development files playing nicely together on my Ubuntu 64-bit dev box.  Each
>> time I find a new, dumb, 32-bit, proprietary package I spend ages creating a
>> set of $PATH, $LD_LIBRARY_PATH and symlinks that will actually get the stupid
>> thing to run.  And those then break my finely tuned environment for the other
>> stupid packages.  I've started creating scripts that set up a good
>> environment, run the program, then tear it down again but that's getting
>> tedious, I've had enough.
>> 
>> My first instinct was just to grab VirtualBox and install a 32-bit machine but
>> surely there's a better, lighter-weight way!  Especially as many of the stupid
>> packages have to talk to host hardware, eg programmers, which aren't
>> completely trivial to punch through a VM.
>> 
>> I've had a brief look at OpenVZ but it looks like when they say 'same OS
>> workloads' they really mean it; I thought they could support parallel
>> distributions so long as they were all Linux-based but it looks like I was
>> wrong.
>> 
>> Anyone got ideas?  Done the same thing?
>> 
>> Thanks,
>> 	--Ben.
>> --
>> linux mailing list
>> linux at lists.samba.org
>> https://lists.samba.org/mailman/listinfo/linux
> 
> --
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux