Modules looks like a VERY useful tool. Thank you. Have to give it a try when I switch to the "experimental" platform!<br><br>Charlie<br><br><div class="gmail_quote">On Tue, Nov 22, 2011 at 3:25 AM, Antoine Monmayrant <span dir="ltr"><<a href="mailto:antoine.monmayrant@laas.fr">antoine.monmayrant@laas.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">By the way, did you try modules to get both libraries at the same time?<br>
( <a href="http://modules.sourceforge.net/" target="_blank">http://modules.sourceforge.<u></u>net/</a> )<br>
It is installed on a cluster I have access to and it's quite efficient.<br>
Basically you can do things like "module load gcc/3.1.1" and "module load scilab/4.1.2" to get gcc3.1.1 and scilab4.1.2 as your default compiler and scilab exe in the current terminal.<br>
I use it to run simultaneously different softwares that have incompatible requirements.<br>
It may be a solution for you.<br>
<br>
Cheers,<br>
<br>
Antoine<br>
<br>
Le 21/11/2011 22:40, Charles Warner a écrit :<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
Just gave chroot a try- works nicely, but my system won't let me run a<br>
second X server, which seems to limit the second root to command line<br>
only. Useful, but not much imporvement over my reboot approach. Note that<br>
I can access files on either system from whatever system is active...I<br>
could run Scilab from the command line on the new root, but, since Scilab<br>
comes installed and configured on my preferred distro, I really have no<br>
need to do this.<br>
<br>
What I use the dual boot system for primarily is to have an "experimental"<br>
system where I can try out new software, check for conflicts, etc. before<br>
adding it to my "working" system. As time goes on, my "experimental"<br>
system starts looking more like my "working" system- when it seems stable<br>
enough, and has all the critical functions I need, I then start using it as<br>
the "working" system, and the old system is discarded and a new base distro<br>
can be explored without causing problems. This also gives me the chance to<br>
evaluate new releases of projects like Scilab without losing my existing<br>
capabilities.<br>
<br>
The conflict between the libgl versions that I encountered actually<br>
occurred when trying to run Dassault Systemes' DraftSight2 (latest release)<br>
on the same platform as Salome. Not being to fond of the idea of rebooting<br>
to switch between systems to resolve library conflicts, and the fact that<br>
an older version of DraftSight2 plays nicely with Salome, and the fact that<br>
Salome is by far the more important package, Salome wins. I am not sure I<br>
could easily make the same choice with Scilab requiring a different library<br>
version- although rebooting to run Scilab is not nearly as unpalatable as<br>
the other two, since I seldom, if ever, need to run Scilab when I am<br>
running Salome. The question is, are ther atoms that rely on one version<br>
of the libgl library while other atoms rely on the other version?<br>
<br>
This is a conflict I have never encountered on Linux before, but, I suspect<br>
that, with the "desktop wars" between Gnome 3 and Unity running rampant, I<br>
suspect we can look for more such conflicts in the future...<br>
<br>
Charlie<br>
<br>
On Mon, Nov 21, 2011 at 3:40 AM, Antoine Monmayrant<<br>
<a href="mailto:antoine.monmayrant@laas.fr" target="_blank">antoine.monmayrant@laas.fr</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
Le 20/11/2011 22:19, Charles Warner a écrit :<br>
<br>
Anttoine-<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
My version of Linux (Ubuntu 10.04) will not allow me to install the two<br>
libraries simultaneously on the same file system. I have not considered<br>
chroot- I don't know if it will find the alternative file system. Worth a<br>
try, I suppose. Since I like to keep two instances of the entire distro<br>
on<br>
my computer (one, my "working" system, one my "experimental" system)<br>
rebooting has always been my "lazy" approach. I'm not sure how to use<br>
chroot in this process, since both systems have root named "/"...maybe<br>
worth experimentings with.<br>
<br>
</blockquote>
Well, we use it at work (I have to admit I was not the one setting it up)<br>
and it's quite convenient.<br>
Basically, the only common points between your two systems will be the<br>
linux kernel.<br>
Apart from the kernel, the two systems are totally independent and have<br>
their one filesystems.<br>
We use it to run a debian distro (that have nice packages for<br>
electromagnetic simulations) on a centos system (needed for a lot of other<br>
simulations softwares).<br>
Switching from Centos to Debian is as easy as "/local/chroot/debian" and<br>
it's even easier to switch back: "exit".<br>
We didn't bother setting up the X server on Debian (the softs we use are<br>
command-line only) but it might be possible to share the same X server on<br>
both systems.<br>
<br>
Cheers,<br>
<br>
Antoine<br>
<br>
Charlie<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
On Sun, Nov 20, 2011 at 3:03 PM, Antoine Monmayrant<<br>
<a href="mailto:antoine.monmayrant@laas.fr" target="_blank">antoine.monmayrant@laas.fr</a>> wrote:<br>
<br>
Le 20/11/11 18:25, Charles Warner a écrit :<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
"install libgl1-mesa-swx11 or removing libgl1-mesa-glx should fix the<br>
issue." The problem is, other software may require libgl1-mesa-glx-<br>
changing to *-swx11 may break something else. The two libraries<br>
apparently<br>
cannot co-exist on the same system. I encountered this with a couple of<br>
other software packages I have been working with- the solution is a dual<br>
boot system, one with *-glx to satisfy one software package, the other<br>
with<br>
*-swx11 to satisfy the other software package. Not an elegant<br>
solution...<br>
<br>
Why don't you chroot instead of dualboot?<br>
This could be a more elegant solution, even if it's not perfect.<br>
<br>
<br></div></div>
On Sun, Nov 20, 2011 at 7:18 AM, Tibault Reveyrand<<a href="mailto:reveyrand@gmail.com" target="_blank">reveyrand@gmail.com</a>><u></u>*<br>
*wrote:<div class="im"><br>
<br>
Here is a way to fix this problem :<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<a href="https://twitter.com/#%21/**SylvestreLedru/status/**138217732360515584" target="_blank">https://twitter.com/#!/**<u></u>SylvestreLedru/status/**<u></u>138217732360515584</a><<a href="https://twitter.com/#%21/SylvestreLedru/status/138217732360515584" target="_blank">https://<u></u>twitter.com/#%21/<u></u>SylvestreLedru/status/<u></u>138217732360515584</a>><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></blockquote></blockquote>
<br>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
</blockquote></div><br>