[scilab-Users] Re: scilab on Ubuntu 11.10

Wed Nov 23 02:09:35 CET 2011

Modules looks like a VERY useful tool.  Thank you.  Have to give it a try
when I switch to the "experimental" platform!

Charlie

On Tue, Nov 22, 2011 at 3:25 AM, Antoine Monmayrant <
antoine.monmayrant at laas.fr> wrote:

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