It looks like sundials (v3.) won’t work with Octave 4.4, only sundials2 (2.7):

http://octave.1599824.n4.nabble.com/sundials-3-td4687354.html 
<http://octave.1599824.n4.nabble.com/sundials-3-td4687354.html>
https://savannah.gnu.org/bugs/?52475 <https://savannah.gnu.org/bugs/?52475>


--Adam



> On Jun 4, 2018, at 11:15 AM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> Welcome to our world!
> 
> How to fix this?...
> 
> you could try using sundials in octave (change the dependency in the 
> Portfile). Maybe sundials2 was just an oversight. If that works, come up with 
> a variant.
> 
> you could disable sundials in octave if you don't want or need it (again, 
> maybe a variant).
> 
> 
> ... 
> 
> 
> On 2018-06-04, at 5:49 AM, Adam Dershowitz wrote:
> 
>> I’m in the same situation (I have openmodelica-devel installed and want to 
>> upgrade octave).  The odd thing is that octave 4.2.2 was working fine with 
>> sundials (which is version 3.1.0_1).  But, the upgrade of octave to 4.4 
>> requires the sundials2 port (2.7.0).  So, somehow it seems that upgrading 
>> octaves requires downgrading sundials.  But, that is not compatible with 
>> openmodelica).  
>> 
>> 
>> --Adam
>> 
>> 
>> 
>>> On Jun 3, 2018, at 10:17 PM, Ken Cunningham 
>>> <ken.cunningham.web...@gmail.com <mailto:ken.cunningham.web...@gmail.com>> 
>>> wrote:
>>> 
>>> The two sundials ports don't have exactly identical file names, but there 
>>> is too much overlap to try a simple naming trick for installing them both 
>>> it appears.
>>> 
>>> If one of the ports you want to install has a bundled copy of sundials that 
>>> you can statically link in, you might get away with that as a quick one-off 
>>> solution. Not a great general solution, but it is done.
>>> 
>>> 
>>> More commonly, you would have to come up with a scheme to install them in 
>>> non-conflicting locations where they can coexist without crashing into each 
>>> other, and then direct the ports that need them to the location.
>>> 
>>> e.g.
>>> 
>>> /opt/local/libexec/sundials/*
>>> /opt/local/libexec/sundials2*
>>> 
>>> or sometimes this pattern is chosen
>>> 
>>> /opt/local/include/sundials/*
>>> /opt/local/include/sundials2/*
>>> /opt/local/lib/sundials/*
>>> /opt/local/lib/sundials2/*
>>> 
>>> 
>>> Sometimes, if one version is far more favoured than the other, the favoured 
>>> version gets the default install location, and the less commonly used one 
>>> gets an alternate location. This can be easier as most ports don't need to 
>>> be modified, but also can generate hassles if the wrong library or header 
>>> collection is found.
>>> 
>>> 
>>> And then, each and every port that uses sundials* needs to be checked 
>>> and/or modified to make sure they find and use the correct versions of the 
>>> headers and libraries.
>>> 
>>> A fair bit of work, to be sure...usually takes a dedicated dev who needs 
>>> them both to work to dive in on this kind of project.
>>> 
>>> Updating ports to all use the latest version of the library is often a 
>>> simpler and better solution, eg the recent ffmpeg project...
>>> 
>>> Ken
>>> 
>>> 
>>> On 2018-06-03, at 2:51 PM, Murray Eisenberg wrote:
>>> 
>>>> The current octave 
>>>> (@4.4.0_2+accelerate+app+docs+gfortran+graphicsmagick+qt5+sound) epends on 
>>>> sundials2.
>>>> openmodelica-dvel depends on sundials. And sundials cannot be installed 
>>>> because it conflicts with sundials2.
>>>> 
>>>> Any way to resolve this?
>>>> 
>>>> 
>>>> ---
>>>> Murray Eisenberg                   murrayeisenb...@gmail.com 
>>>> <mailto:murrayeisenb...@gmail.com>
>>>> 503 King Farm Blvd #101    Home (240)-246-7240
>>>> Rockville, MD 20850-6667   Mobile (413)-427-5334
>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to