Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Adam Dershowitz]

It took me a while to actually try this.  But, it does seem to work fine.  I 
would encourage someone to push this change to the port file.

Thanks for creating this diff.

--Adam



> On Jun 6, 2018, at 1:20 AM, Ken Cunningham  
> wrote:
> 
> Adam, Murray -- This small patch will patch the octave Portfile to make 
> sundials2 support a variant.
> If you want to install octave without sundials2 support (so you can use 
> openmodelica which needs sundials) this should allow you to do that.
> 
> The command is:
> 
> sudo port -v install octave -sundials2
> 
> I built octave locally without sundials2 support and it seems to build 
> cleanly.
> 
> I don't know how many people might want to install both octave and 
> openmodelica.
> If there are enough people, perhaps Marcus /Marius might add something like 
> this into the octave Portfile.
> 
> Best,
> 
> Ken
> 
> --- patch below ---
> 
> --- Portfile  2018-06-02 16:18:27.0 -0700
> +++ Portfile  2018-06-05 22:14:12.0 -0700
> @@ -295,6 +295,11 @@
> --without-magick\
> --disable-docs
> 
> +#default to no sundials support - see variant below
> +configure.args-append   \
> +--without-sundials_nvecserial \
> +--without-sundials_ida
> +
> # in configure.ac, listed as one of "[p]rograms used when running Octave"
> depends_lib-append port:python27
> configure.python ${prefix}/bin/python2.7
> @@ -365,10 +370,6 @@
> configure.args-append --without-openssl
> #depends_lib-append path:lib/libssl.dylib:openssl
> 
> -#--without-sundials_nvecserial
> -#--without-sundials_ida
> -depends_lib-append  port:sundials2
> -
> # see etc/README.MacOS
> depends_run-append   \
> port:epstool \
> @@ -399,6 +400,13 @@
> #https://trac.macports.org/ticket/51480
> #default_variants-append +java
> 
> +variant sundials2 description {build with sundials2 support - not compatible 
> with sundials} {
> +depends_lib-append  port:sundials2
> +configure.args-delete --without-sundials_nvecserial
> +configure.args-delete --without-sundials_ida
> +}
> +default_variants-append +sundials2
> +
> variant qt4 conflicts qt5 description {build the GUI using Qt4} {
> PortGroup qt4 1.0
> depends_lib-append port:qscintilla-qt4
> 

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Ken Cunningham]

Adam, Murray -- This small patch will patch the octave Portfile to make 
sundials2 support a variant.
If you want to install octave without sundials2 support (so you can use 
openmodelica which needs sundials) this should allow you to do that.

The command is:

sudo port -v install octave -sundials2

I built octave locally without sundials2 support and it seems to build cleanly.

I don't know how many people might want to install both octave and openmodelica.
If there are enough people, perhaps Marcus /Marius might add something like 
this into the octave Portfile.

Best,

Ken

--- patch below ---

--- Portfile2018-06-02 16:18:27.0 -0700
+++ Portfile2018-06-05 22:14:12.0 -0700
@@ -295,6 +295,11 @@
 --without-magick\
 --disable-docs
 
+#default to no sundials support - see variant below
+configure.args-append   \
+--without-sundials_nvecserial \
+--without-sundials_ida
+
 # in configure.ac, listed as one of "[p]rograms used when running Octave"
 depends_lib-append port:python27
 configure.python ${prefix}/bin/python2.7
@@ -365,10 +370,6 @@
 configure.args-append --without-openssl
 #depends_lib-append path:lib/libssl.dylib:openssl
 
-#--without-sundials_nvecserial
-#--without-sundials_ida
-depends_lib-append  port:sundials2
-
 # see etc/README.MacOS
 depends_run-append   \
 port:epstool \
@@ -399,6 +400,13 @@
 #https://trac.macports.org/ticket/51480
 #default_variants-append +java
 
+variant sundials2 description {build with sundials2 support - not compatible 
with sundials} {
+depends_lib-append  port:sundials2
+configure.args-delete --without-sundials_nvecserial
+configure.args-delete --without-sundials_ida
+}
+default_variants-append +sundials2
+
 variant qt4 conflicts qt5 description {build the GUI using Qt4} {
 PortGroup qt4 1.0
 depends_lib-append port:qscintilla-qt4

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Ken Cunningham]

On 2018-06-04, at 8:22 AM, Adam Dershowitz wrote:

>>> The odd thing is that octave 4.2.2 was working fine with sundials (which is 
>>> version 3.1.0_1)

This doesn't seem too likely, unless Octave was ignoring sundials.

Why don't you try deleting the sundials dependency in the Octave portfile and 
see what happens then? We only added the sundials dep fairly recently I believe.

here's the important bit in the Portfile

#--without-sundials_nvecserial
#--without-sundials_ida
depends_lib-append  port:sundials2


so looks like you would delete this line:

depends_lib-append  port:sundials2

and add these two to the configure args.

--without-sundials_nvecserial
--without-sundials_ida


might not be too hard if you can live without sundials




Ken

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Adam Dershowitz]

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  
> 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 
>>> 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 #101Home (240)-246-7240
>>>> Rockville, MD 20850-6667   Mobile (413)-427-5334
>>>> 
>>>> 
>>> 
>> 
> 

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Ken Cunningham]

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 
>>  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 Eisenbergmurrayeisenb...@gmail.com
>>> 503 King Farm Blvd #101 Home (240)-246-7240
>>> Rockville, MD 20850-6667Mobile (413)-427-5334
>>> 
>>> 
>> 
> 

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Adam Dershowitz]

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  
> 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
>> 
>> 
> 

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Ken Cunningham]

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
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 

How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Murray Eisenberg]

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 Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Murray Eisenberg]

I have solved the problem by uninstalling other MacPorts that used the atlas 
libraries, including octave, qrupdate, and arpack; then installing those 
dependencies with the +accelerate variant; and finally installing 
openmodelica-devel+gfortran5+libraries+omnotebook+qt+sundials. 

I hope that, contrary to what is still posted on the Gnu Octave, the Apple 
libraries are now sufficiently error-free that the atlas libraries are not 
actually needed (We'll see!) 

Thanks to all who replied about this issue.

> On 16 Apr2018, at 4:50 PM, Murray Eisenberg <murrayeisenb...@gmail.com> wrote:
> 
> After uninstalling the +atlas variant of octave and its direct or indirect 
> deps or dependent’s sundials, SuiteSparse. qrupdate, and arpack, I began 
> reinstalling with the +accelerate variant.
> 
> I used (with sudo):
> 
>   port install octave 
> +app+accelerate+docs+fltk+gfortran+graphicsmagick+qt5+sound 
> 
> but when the octave installation was running it tried to install qrupdate and 
> hit error:
> 
>   Error: Failed to fetch qrupdate: must set at least one Fortran variant 
> (e.g. +gfortran, +gccX, +g95)
> 
> So I quit that, cleaned everything, and directly tried...
> 
>   port install qrupdate +accelerate +gfortran
> 
> … and got same error message that I must set a Fortran variant.
> 
> Now I’m puzzled: the qrupdate port says +gfortran is such a variant, then 
> fails to accept it.  And in fact:
> 
> port info qrupdate
> qrupdate @1.1.2_5 (math)
> Variants: [+]accelerate, atlas, g95, gcc44, gcc45, gcc46, gcc47,
>   gcc48, gcc49, gcc5, gcc6, [+]gcc7, openblas, universal
> 
> (I see what Ken Cunningham said in separate message about blowing up MacPorts 
> and starting over, but I have quite a number of config files, e.g., for 
> apache, mysql, php, phpmyadmin, that I’d hate to set up again; that could 
> take days. Unless I misunderstand what Ken said.)
> 
>> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu 
>> <mailto:de...@alum.mit.edu>> wrote:
>> 
>> As an datapoint, but not completely answering your question.  I have the 
>> following installed and all working:
>> 
>> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
>> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
>> (active)
>> SuiteSparse @4.2.1_4+accelerate (active)
>> openmodelica-devel 
>> @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials (active)
>> 
>> 
>> I don’t recall the installation order, or if any of those are not the 
>> default variant.  
>> 
>> --Adam
>> 
>> 
>> 
>>> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>>> <mailto:murrayeisenb...@gmail.com>> wrote:
>>> 
>>> From a post on the OpenModelica forum, I learned that the trouble was that 
>>> I did not have the lapack port installed, and so the openmodelica-devel 
>>> configure was attempting to use libatlas from atlas instead.
>>> 
>>> Subsequently, after cleaning everything, I did install lapack 
>>> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
>>> due to the fact that the following both involve atlas:
>>> 
>>>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>>>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>>> 
>>> I wonder if the following ploy might work (this is the MacPorts part of the 
>>> question):
>>> 
>>>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>>> 
>>>(2) install openmodelica-devel (assuming that the presence of atlas and 
>>> libatlas was the sole issue); then finally
>>> 
>>>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>>> 
>>> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
>>> sundials has a library dependency on SuiteSparse.
>>> 
>>> Further information:
>>> 
>>> [me:~]$ sp dependent atlas
>>> SuiteSparse depends on atlas
>>> arpack depends on atlas
>>> octave depends on atlas
>>> qrupdate depends on atlas
>>> 
>>> [me:~]$ sp deps octave
>>> Full Name: octave 
>>> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
>>> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
>>> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
>>> texlive-basic, texlive-latex, texlive-fonts-recommended
>>> L

Re: OpenModelica?

[Ryan Schmidt]

On Apr 16, 2018, at 15:50, Murray Eisenberg wrote:

>   Error: Failed to fetch qrupdate: must set at least one Fortran variant 
> (e.g. +gfortran, +gccX, +g95)
> 

This message is printed by the compilers-1.0 portgroup, and is not customized 
for the set of variants that a particular port offers: It will always suggest 
using "e.g. +gfortran, +gccX, +g95" even if the specific port you're trying to 
install doesn't offer all of those variants. That's a bug in the portgroup, and 
I've filed a ticket about it:

https://trac.macports.org/ticket/56310

Re: OpenModelica?

[Adam Dershowitz]

It looks like the default variant of qrupdate is +accelerate +gcc7 already.  
So, you can try, simply:
sudo port install qrupdate



--Adam



> On Apr 16, 2018, at 4:50 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
> wrote:
> 
> After uninstalling the +atlas variant of octave and its direct or indirect 
> deps or dependent’s sundials, SuiteSparse. qrupdate, and arpack, I began 
> reinstalling with the +accelerate variant.
> 
> I used (with sudo):
> 
>   port install octave 
> +app+accelerate+docs+fltk+gfortran+graphicsmagick+qt5+sound 
> 
> but when the octave installation was running it tried to install qrupdate and 
> hit error:
> 
>   Error: Failed to fetch qrupdate: must set at least one Fortran variant 
> (e.g. +gfortran, +gccX, +g95)
> 
> So I quit that, cleaned everything, and directly tried...
> 
>   port install qrupdate +accelerate +gfortran
> 
> … and got same error message that I must set a Fortran variant.
> 
> Now I’m puzzled: the qrupdate port says +gfortran is such a variant, then 
> fails to accept it.  And in fact:
> 
> port info qrupdate
> qrupdate @1.1.2_5 (math)
> Variants: [+]accelerate, atlas, g95, gcc44, gcc45, gcc46, gcc47,
>   gcc48, gcc49, gcc5, gcc6, [+]gcc7, openblas, universal
> 
> (I see what Ken Cunningham said in separate message about blowing up MacPorts 
> and starting over, but I have quite a number of config files, e.g., for 
> apache, mysql, php, phpmyadmin, that I’d hate to set up again; that could 
> take days. Unless I misunderstand what Ken said.)
> 
>> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu 
>> <mailto:de...@alum.mit.edu>> wrote:
>> 
>> As an datapoint, but not completely answering your question.  I have the 
>> following installed and all working:
>> 
>> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
>> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
>> (active)
>> SuiteSparse @4.2.1_4+accelerate (active)
>> openmodelica-devel 
>> @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials (active)
>> 
>> 
>> I don’t recall the installation order, or if any of those are not the 
>> default variant.  
>> 
>> --Adam
>> 
>> 
>> 
>>> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>>> <mailto:murrayeisenb...@gmail.com>> wrote:
>>> 
>>> From a post on the OpenModelica forum, I learned that the trouble was that 
>>> I did not have the lapack port installed, and so the openmodelica-devel 
>>> configure was attempting to use libatlas from atlas instead.
>>> 
>>> Subsequently, after cleaning everything, I did install lapack 
>>> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
>>> due to the fact that the following both involve atlas:
>>> 
>>>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>>>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>>> 
>>> I wonder if the following ploy might work (this is the MacPorts part of the 
>>> question):
>>> 
>>>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>>> 
>>>(2) install openmodelica-devel (assuming that the presence of atlas and 
>>> libatlas was the sole issue); then finally
>>> 
>>>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>>> 
>>> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
>>> sundials has a library dependency on SuiteSparse.
>>> 
>>> Further information:
>>> 
>>> [me:~]$ sp dependent atlas
>>> SuiteSparse depends on atlas
>>> arpack depends on atlas
>>> octave depends on atlas
>>> qrupdate depends on atlas
>>> 
>>> [me:~]$ sp deps octave
>>> Full Name: octave 
>>> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
>>> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
>>> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
>>> texlive-basic, texlive-latex, texlive-fonts-recommended
>>> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, 
>>> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, 
>>> glpk, curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>>>  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
>>> portaudio, GraphicsMagick, qt5-qtbase, 

Re: OpenModelica?

[Murray Eisenberg]

After uninstalling the +atlas variant of octave and its direct or indirect deps 
or dependent’s sundials, SuiteSparse. qrupdate, and arpack, I began 
reinstalling with the +accelerate variant.

I used (with sudo):

  port install octave 
+app+accelerate+docs+fltk+gfortran+graphicsmagick+qt5+sound 

but when the octave installation was running it tried to install qrupdate and 
hit error:

  Error: Failed to fetch qrupdate: must set at least one Fortran variant (e.g. 
+gfortran, +gccX, +g95)

So I quit that, cleaned everything, and directly tried...

  port install qrupdate +accelerate +gfortran

… and got same error message that I must set a Fortran variant.

Now I’m puzzled: the qrupdate port says +gfortran is such a variant, then fails 
to accept it.  And in fact:

port info qrupdate
qrupdate @1.1.2_5 (math)
Variants: [+]accelerate, atlas, g95, gcc44, gcc45, gcc46, gcc47,
  gcc48, gcc49, gcc5, gcc6, [+]gcc7, openblas, universal

(I see what Ken Cunningham said in separate message about blowing up MacPorts 
and starting over, but I have quite a number of config files, e.g., for apache, 
mysql, php, phpmyadmin, that I’d hate to set up again; that could take days. 
Unless I misunderstand what Ken said.)

> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu> wrote:
> 
> As an datapoint, but not completely answering your question.  I have the 
> following installed and all working:
> 
> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
> (active)
> SuiteSparse @4.2.1_4+accelerate (active)
> openmodelica-devel 
> @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials (active)
> 
> 
> I don’t recall the installation order, or if any of those are not the default 
> variant.  
> 
> --Adam
> 
> 
> 
>> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>> <mailto:murrayeisenb...@gmail.com>> wrote:
>> 
>> From a post on the OpenModelica forum, I learned that the trouble was that I 
>> did not have the lapack port installed, and so the openmodelica-devel 
>> configure was attempting to use libatlas from atlas instead.
>> 
>> Subsequently, after cleaning everything, I did install lapack 
>> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
>> due to the fact that the following both involve atlas:
>> 
>>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>> 
>> I wonder if the following ploy might work (this is the MacPorts part of the 
>> question):
>> 
>>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>> 
>>(2) install openmodelica-devel (assuming that the presence of atlas and 
>> libatlas was the sole issue); then finally
>> 
>>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>> 
>> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
>> sundials has a library dependency on SuiteSparse.
>> 
>> Further information:
>> 
>> [me:~]$ sp dependent atlas
>> SuiteSparse depends on atlas
>> arpack depends on atlas
>> octave depends on atlas
>> qrupdate depends on atlas
>> 
>> [me:~]$ sp deps octave
>> Full Name: octave 
>> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
>> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
>> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
>> texlive-basic, texlive-latex, texlive-fonts-recommended
>> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, 
>> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, glpk, 
>> curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>>  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
>> portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
>> Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit
>> 
>> [me:~]$ sp deps openmodelica-devel 
>> Full Name: openmodelica-devel 
>> @1.13.0~dev-895-g0365526_0+gfortran5+omnotebook+qt+sundials
>> Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake, 
>> libtool
>> Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc, 
>> gcc5, sundials, qt4-mac, qwt52
>> Runtime Dependencies: omlib-modelica-3.2.1
>> 
>>> On 7 Apr2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com 
>>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>> 
>>> 
>

Re: OpenModelica?

[Ken Cunningham]

Whenever I get to this level of hassle, I just blow up MacPorts and start over.

It takes but a few minutes to reinstall the prebuilt binaries, and then you 
know you're clean.

Life is too short 


Ken

Re: OpenModelica?

[David Strubbe]

I believe the "known bugs" in question for use of Accelerate may be fixed
by our current use of the veclibfort port as an intermediate layer between
Fortran and Accelerate.

David

On Mon, Apr 16, 2018 at 1:27 PM, Adam Dershowitz <de...@alum.mit.edu> wrote:

> I wasn’t able to confirm if that bug still exists.  It seems that it was
> an old bug.  The bug report from 2014 for octave makes it sound like might
> have been fixed years before that:
>
> https://savannah.gnu.org/bugs/?43246
>
> So, you might try to use the default builds and then run on a test on
> whatever functions in Octave might be an issue?
>
> --Adam
>
>
>
> On Apr 16, 2018, at 4:20 PM, Murray Eisenberg <murrayeisenb...@gmail.com>
> wrote:
>
> The information at https://wiki.octave.org/Octave_for_macOS is that the
> default octave uses the accelerator variant.
>
> But this has the problem that is uses arpack, whose default variant is
> accelerate; this uses Apples Vector Libraries which have some known bugs
> that can cause Octave to crash if certain functions in arpack are called!
>
> So they recomend using the atlas port of octace (hence of arpack and
> SparseSuite, too, I presume).
>
> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu> wrote:
>
> As an datapoint, but not completely answering your question.  I have the
> following installed and all working:
>
> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound
> (active)
> SuiteSparse @4.2.1_4+accelerate (active)
> openmodelica-devel @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials
> (active)
>
>
> I don’t recall the installation order, or if any of those are not the
> default variant.
>
> --Adam
>
>
>
> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com>
> wrote:
>
> From a post on the OpenModelica forum, I learned that the trouble was that
> I did not have the lapack port installed, and so the openmodelica-devel
> configure was attempting to use libatlas from atlas instead.
>
> Subsequently, after cleaning everything, I did install lapack
> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is
> due to the fact that the following both involve atlas:
>
>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound
>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>
> I wonder if the following ploy might work (this is the MacPorts part of
> the question):
>
>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>
>(2) install openmodelica-devel (assuming that the presence of atlas and
> libatlas was the sole issue); then finally
>
>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>
> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And
> sundials has a library dependency on SuiteSparse.
>
> Further information:
>
> [me:~]$ sp dependent atlas
> SuiteSparse depends on atlas
> arpack depends on atlas
> octave depends on atlas
> qrupdate depends on atlas
>
> [me:~]$ sp deps octave
> Full Name: octave @4.2.2_1+accelerate+app+docs+
> fltk+gfortran+graphicsmagick+qt5+sound
> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed,
> flex, bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo,
> texlive-basic, texlive-latex, texlive-fonts-recommended
> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses,
> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single,
> glpk, curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>  vecLibFort, libgcc, qscintilla-qt5, fltk,
> libsndfile, portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
> Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit
>
> [me:~]$ sp deps openmodelica-devel
> Full Name: openmodelica-devel @1.13.0~dev-895-g0365526_0+
> gfortran5+omnotebook+qt+sundials
> Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake,
> libtool
> Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc,
> gcc5, sundials, qt4-mac, qwt52
> Runtime Dependencies: omlib-modelica-3.2.1
>
> On 7 Apr2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com>
> wrote:
>
>
>
> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg <murrayeisenb...@gmail.com>
> wrote:
>
>
> With a small change in the openmodelica-devel Portfile that I did prior to
> starting the build (so it would use gcc7 for fortran), all of
> openmodelica-devel built through to completion for me on a current Xcode
> and 10.13 system, using no compiler va

Re: OpenModelica?

[Adam Dershowitz]

I wasn’t able to confirm if that bug still exists.  It seems that it was an old 
bug.  The bug report from 2014 for octave makes it sound like might have been 
fixed years before that:

https://savannah.gnu.org/bugs/?43246 <https://savannah.gnu.org/bugs/?43246>

So, you might try to use the default builds and then run on a test on whatever 
functions in Octave might be an issue?

--Adam



> On Apr 16, 2018, at 4:20 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
> wrote:
> 
> The information at https://wiki.octave.org/Octave_for_macOS 
> <https://wiki.octave.org/Octave_for_macOS> is that the default octave uses 
> the accelerator variant. 
> 
> But this has the problem that is uses arpack, whose default variant is 
> accelerate; this uses Apples Vector Libraries which have some known bugs that 
> can cause Octave to crash if certain functions in arpack are called!
> 
> So they recomend using the atlas port of octace (hence of arpack and 
> SparseSuite, too, I presume).
> 
>> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu 
>> <mailto:de...@alum.mit.edu>> wrote:
>> 
>> As an datapoint, but not completely answering your question.  I have the 
>> following installed and all working:
>> 
>> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
>> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
>> (active)
>> SuiteSparse @4.2.1_4+accelerate (active)
>> openmodelica-devel 
>> @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials (active)
>> 
>> 
>> I don’t recall the installation order, or if any of those are not the 
>> default variant.  
>> 
>> --Adam
>> 
>> 
>> 
>>> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>>> <mailto:murrayeisenb...@gmail.com>> wrote:
>>> 
>>> From a post on the OpenModelica forum, I learned that the trouble was that 
>>> I did not have the lapack port installed, and so the openmodelica-devel 
>>> configure was attempting to use libatlas from atlas instead.
>>> 
>>> Subsequently, after cleaning everything, I did install lapack 
>>> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
>>> due to the fact that the following both involve atlas:
>>> 
>>>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>>>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>>> 
>>> I wonder if the following ploy might work (this is the MacPorts part of the 
>>> question):
>>> 
>>>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>>> 
>>>(2) install openmodelica-devel (assuming that the presence of atlas and 
>>> libatlas was the sole issue); then finally
>>> 
>>>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>>> 
>>> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
>>> sundials has a library dependency on SuiteSparse.
>>> 
>>> Further information:
>>> 
>>> [me:~]$ sp dependent atlas
>>> SuiteSparse depends on atlas
>>> arpack depends on atlas
>>> octave depends on atlas
>>> qrupdate depends on atlas
>>> 
>>> [me:~]$ sp deps octave
>>> Full Name: octave 
>>> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
>>> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
>>> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
>>> texlive-basic, texlive-latex, texlive-fonts-recommended
>>> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, 
>>> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, 
>>> glpk, curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>>>  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
>>> portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
>>> Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit
>>> 
>>> [me:~]$ sp deps openmodelica-devel 
>>> Full Name: openmodelica-devel 
>>> @1.13.0~dev-895-g0365526_0+gfortran5+omnotebook+qt+sundials
>>> Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake, 
>>> libtool
>>> Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc, 
>>> gcc5, sundials, qt4-mac, qwt52
>>> Runtime Dependencies: omlib-modelica-3.2.1
>>> 
>>>> On 7 Apr2018,

Re: OpenModelica?

[Murray Eisenberg]

The information at https://wiki.octave.org/Octave_for_macOS 
<https://wiki.octave.org/Octave_for_macOS> is that the default octave uses the 
accelerator variant. 

But this has the problem that is uses arpack, whose default variant is 
accelerate; this uses Apples Vector Libraries which have some known bugs that 
can cause Octave to crash if certain functions in arpack are called!

So they recomend using the atlas port of octace (hence of arpack and 
SparseSuite, too, I presume).

> On 16 Apr2018, at 3:55 PM, Adam Dershowitz <de...@alum.mit.edu> wrote:
> 
> As an datapoint, but not completely answering your question.  I have the 
> following installed and all working:
> 
> sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
> octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
> (active)
> SuiteSparse @4.2.1_4+accelerate (active)
> openmodelica-devel 
> @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials (active)
> 
> 
> I don’t recall the installation order, or if any of those are not the default 
> variant.  
> 
> --Adam
> 
> 
> 
>> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>> <mailto:murrayeisenb...@gmail.com>> wrote:
>> 
>> From a post on the OpenModelica forum, I learned that the trouble was that I 
>> did not have the lapack port installed, and so the openmodelica-devel 
>> configure was attempting to use libatlas from atlas instead.
>> 
>> Subsequently, after cleaning everything, I did install lapack 
>> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
>> due to the fact that the following both involve atlas:
>> 
>>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
>> 
>> I wonder if the following ploy might work (this is the MacPorts part of the 
>> question):
>> 
>>(1) uninstalling the +atlas variants of SuiteSparse and octave;
>> 
>>(2) install openmodelica-devel (assuming that the presence of atlas and 
>> libatlas was the sole issue); then finally
>> 
>>(3) reinstalling the +atlas variants of octave and SuiteSparse.
>> 
>> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
>> sundials has a library dependency on SuiteSparse.
>> 
>> Further information:
>> 
>> [me:~]$ sp dependent atlas
>> SuiteSparse depends on atlas
>> arpack depends on atlas
>> octave depends on atlas
>> qrupdate depends on atlas
>> 
>> [me:~]$ sp deps octave
>> Full Name: octave 
>> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
>> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
>> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
>> texlive-basic, texlive-latex, texlive-fonts-recommended
>> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, 
>> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, glpk, 
>> curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>>  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
>> portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
>> Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit
>> 
>> [me:~]$ sp deps openmodelica-devel 
>> Full Name: openmodelica-devel 
>> @1.13.0~dev-895-g0365526_0+gfortran5+omnotebook+qt+sundials
>> Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake, 
>> libtool
>> Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc, 
>> gcc5, sundials, qt4-mac, qwt52
>> Runtime Dependencies: omlib-modelica-3.2.1
>> 
>>> On 7 Apr2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com 
>>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>>>> <mailto:murrayeisenb...@gmail.com>> wrote:
>>> 
>>> With a small change in the openmodelica-devel Portfile that I did prior to 
>>> starting the build (so it would use gcc7 for fortran), all of 
>>> openmodelica-devel built through to completion for me on a current Xcode 
>>> and 10.13 system, using no compiler variants, and only +libraries.
>>> 
>>> set gfortran_versions {4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 6 7}
>>> set default_fortran_variant +gfortran7
>>> 
>>> 
>>> Ken
>> 
>> ---
>> 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
>> 
>> 
> 

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Adam Dershowitz]

As an datapoint, but not completely answering your question.  I have the 
following installed and all working:

sundials @3.1.0_1+accelerate+fortran_klu+gfortran+mpich (active)
octave @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound 
(active)
SuiteSparse @4.2.1_4+accelerate (active)
openmodelica-devel @1.13.0~dev-882-g45503fc_0+gfortran5+omnotebook+qt+sundials 
(active)


I don’t recall the installation order, or if any of those are not the default 
variant.  

--Adam



> On Apr 16, 2018, at 3:39 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
> wrote:
> 
> From a post on the OpenModelica forum, I learned that the trouble was that I 
> did not have the lapack port installed, and so the openmodelica-devel 
> configure was attempting to use libatlas from atlas instead.
> 
> Subsequently, after cleaning everything, I did install lapack 
> @3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is 
> due to the fact that the following both involve atlas:
> 
>octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
>SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]
> 
> I wonder if the following ploy might work (this is the MacPorts part of the 
> question):
> 
>(1) uninstalling the +atlas variants of SuiteSparse and octave;
> 
>(2) install openmodelica-devel (assuming that the presence of atlas and 
> libatlas was the sole issue); then finally
> 
>(3) reinstalling the +atlas variants of octave and SuiteSparse.
> 
> Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
> sundials has a library dependency on SuiteSparse.
> 
> Further information:
> 
> [me:~]$ sp dependent atlas
> SuiteSparse depends on atlas
> arpack depends on atlas
> octave depends on atlas
> qrupdate depends on atlas
> 
> [me:~]$ sp deps octave
> Full Name: octave 
> @4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
> Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
> bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
> texlive-basic, texlive-latex, texlive-fonts-recommended
> Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, 
> readline, pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, glpk, 
> curl, qrupdate, arpack, fontconfig, freetype, gl2ps,
>  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
> portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
> Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit
> 
> [me:~]$ sp deps openmodelica-devel 
> Full Name: openmodelica-devel 
> @1.13.0~dev-895-g0365526_0+gfortran5+omnotebook+qt+sundials
> Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake, 
> libtool
> Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc, 
> gcc5, sundials, qt4-mac, qwt52
> Runtime Dependencies: omlib-modelica-3.2.1
> 
>> On 7 Apr2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
>> wrote:
>> 
>> 
>> 
>>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
>>> wrote:
>> 
>> With a small change in the openmodelica-devel Portfile that I did prior to 
>> starting the build (so it would use gcc7 for fortran), all of 
>> openmodelica-devel built through to completion for me on a current Xcode and 
>> 10.13 system, using no compiler variants, and only +libraries.
>> 
>> set gfortran_versions {4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 6 7}
>> set default_fortran_variant +gfortran7
>> 
>> 
>> Ken
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 

Re: OpenModelica?

[Murray Eisenberg]

From a post on the OpenModelica forum, I learned that the trouble was that I 
did not have the lapack port installed, and so the openmodelica-devel configure 
was attempting to use libatlas from atlas instead.

Subsequently, after cleaning everything, I did install lapack 
@3.8.0_0+gfortran. However, the configure still fails. Undoubtedly this is due 
to the fact that the following both involve atlas:

octave @4.2.2_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt5+sound 
SuiteSparse @4.2.1_4+atlas  [NB: octave depends on SuiteSparse]

I wonder if the following ploy might work (this is the MacPorts part of the 
question):

(1) uninstalling the +atlas variants of SuiteSparse and octave;

(2) install openmodelica-devel (assuming that the presence of atlas and 
libatlas was the sole issue); then finally

(3) reinstalling the +atlas variants of octave and SuiteSparse.

Note that openmodelica _seems_ to use SuiteSparse as well as lapack. And 
sundials has a library dependency on SuiteSparse.

Further information:

[me:~]$ sp dependent atlas
SuiteSparse depends on atlas
arpack depends on atlas
octave depends on atlas
qrupdate depends on atlas

[me:~]$ sp deps octave
Full Name: octave 
@4.2.2_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt5+sound
Build Dependencies:   gawk, icoutils, librsvg, grep, findutils, gsed, flex, 
bison, gperf, perl5, pkgconfig, gcc7, pkgconfig, librsvg, texinfo, 
texlive-basic, texlive-latex, texlive-fonts-recommended
Library Dependencies: python27, ghostscript, gnuplot, less, ncurses, readline, 
pcre, SuiteSparse, qhull, zlib, hdf5, fftw-3, fftw-3-single, glpk, curl, 
qrupdate, arpack, fontconfig, freetype, gl2ps,
  vecLibFort, libgcc, qscintilla-qt5, fltk, libsndfile, 
portaudio, GraphicsMagick, qt5-qtbase, qt5-qttools
Runtime Dependencies: epstool, ghostscript, fig2dev, pstoedit

[me:~]$ sp deps openmodelica-devel 
Full Name: openmodelica-devel 
@1.13.0~dev-895-g0365526_0+gfortran5+omnotebook+qt+sundials
Build Dependencies:   gtime, gsed, cmake, pkgconfig, autoconf, automake, libtool
Library Dependencies: lp_solve, gettext, omniorb, readline, qjson, libgcc, 
gcc5, sundials, qt4-mac, qwt52
Runtime Dependencies: omlib-modelica-3.2.1

> On 7 Apr2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
>> wrote:
> 
> With a small change in the openmodelica-devel Portfile that I did prior to 
> starting the build (so it would use gcc7 for fortran), all of 
> openmodelica-devel built through to completion for me on a current Xcode and 
> 10.13 system, using no compiler variants, and only +libraries.
> 
> set gfortran_versions {4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 6 7}
> set default_fortran_variant +gfortran7
> 
> 
> Ken

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Ryan Schmidt]

On Apr 7, 2018, at 15:13, Murray Eisenberg wrote:

> Would it be appropriate to open a ticket http://trac.macports.org?

No, since we were not involved in the creation of the openmodelica portfiles 
nor do we host them in our repository, and we have no influence over those who 
do host them to make any modifications. Send your problem report to the people 
who host the portfiles, i.e. the openmodelica people.

> (I will post to the forum at openmodeler.org, in any case.)

Re: OpenModelica?

[Ryan Schmidt]

On Apr 7, 2018, at 15:02, Ken Cunningham wrote:

> Also, installing both gcc5 and gcc7 and libgcc6 and libgcc just seems nutty, 
> so I added gcc6 and gcc7 to the fortran variants — but that has nothing to do 
> with the above.

Using both gcc5 and gcc7 in a single port would indeed be nutty, if indeed they 
are doing that. Using gcc5 in one port and gcc7 in a different port is 
acceptable, though not ideal.

gcc6 and earlier require both libgcc6 and libgcc. This is normal. Just as gcc45 
and earlier require libgcc45, libgcc6, and libgcc. libgcc provides the current 
stable version of all the gcc libraries, currently those of gcc7. libgcc6 
provides the versions of the gcc libraries that were used by gcc6, where that 
differs from gcc7 (which is only libgfortran). libgcc45 provides the versions 
of the gcc libraries that were used by gcc45, where that differs from gcc6 
(which is libobjc-gnu).

Re: OpenModelica?

[Michael Parson]

On Sat, 7 Apr 2018, Murray Eisenberg wrote:


I’m trying to install the port of OpenModelica. The instructions at 
https://www.openmodelica.org/download/download-mac 
<https://www.openmodelica.org/download/download-mac> give, as first step:

   echo rsync://build-openmodelica.org/macports/ >> 
/opt/local/etc/macports/sources.conf

But even with sudo, I’m getting a "Permission denied" error.

How to fix this?


I know I'm for offering a solution to you for this one case, but it can
be done with 'sudo' with a trick.  The 'sudo' command, by design, does
not allow you to directly redirect output to a file.  It's a (minimal)
security feature, to prevent people from using sudo that is more locked
down to certain commands from being able to use sudo to modify files
they might otherwise not have permission to...

The workaround is to use the 'tee' command:

echo rsync://build-openmodelica.org/macports/ | sudo tee -a 
/opt/local/etc/macports/sources.conf

The 'echo' will be sent to your screen as well as appended to the
designated file via the 'tee'.  The '-a' flag tells it to append, which
is what your '>>' in the original command would have done.

--
Michael Parson
Pflugerville, TX
KF5LGQ

Re: OpenModelica?

[Adam Dershowitz]

> On Apr 7, 2018, at 4:34 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
>> wrote:
> 
> With a small change in the openmodelica-devel Portfile that I did prior to 
> starting the build (so it would use gcc7 for fortran), all of 
> openmodelica-devel built through to completion for me on a current Xcode and 
> 10.13 system, using no compiler variants, and only +libraries.
> 
> set gfortran_versions {4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 6 7}
> set default_fortran_variant +gfortran7
> 
> 
> Ken

And, for me it builds and installs just fine with the existing port file, and 
with the default variants:
sudo port install openmodelica-devel
(optionally adding +libraries to download the separate set of modelica 
libraries to use in openmodelica)

Re: OpenModelica?

[Murray Eisenberg]

Indeed, a major hiccup in the installation (which I did _without_ using the 
+clang variant).

From 
/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/config.log
 :

config.status:752: creating Makefile
configure:4318: === configuring in OMCompiler 
(/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/OMCompiler)
configure:4381: running /bin/sh ./configure --disable-option-checking 
'--prefix=/opt/local'  '--disable-python-interface' '--disable-modelica3d' 
'--with-lapack=-llapack -lblas' '--without-omc' '--without-omlibrary' 
'OMPCC=/opt/local/bin/gcc-mp-5 -fopenmp -mno-avx' 
'GNUCXX=/opt/local/bin/g++-mp-5' '--with-omniORB=/opt/local' 
'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64' 'LDFLAGS=-L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64' 'CPPFLAGS=-I/opt/local/include' 
'--with-ombuilddir=/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/build'
 --cache-file=/dev/null --srcdir=.
configure:4386: error: ./configure failed for OMCompiler

And from 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/main.log
 :

:info:configure checking LAPACK/BLAS flags... configure: error: dgesv (LAPACK) 
linking failed using -llapack -lblas
:info:configure configure: error: ./configure failed for OMCompiler
:info:configure Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6"
 && ./configure --prefix=/opt/local --disable-python-interface 
--disable-modelica3d --with-lapack="-llapack -lblas" --without-omc 
--without-omlibrary OMPCC="/opt/local/bin/gcc-mp-5 -fopenmp -mno-avx" 
GNUCXX=/opt/local/bin/g++-mp-5 --with-omniORB=/opt/local 
:info:configure Exit code: 1
:error:configure Failed to configure openmodelica-devel, consult 
/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/config.log
:error:configure Failed to configure openmodelica-devel: configure failure: 
command execution failed


Would it be appropriate to open a ticket http://trac.macports.org? 
<http://trac.macports.org/?> (I will post to the forum at openmodeler.org 
<http://openmodeler.org/>, in any case.)

> On 7 Apr2018, at 4:02 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>> <mailto:murrayeisenb...@gmail.com>> wrote:
>> 
>> Ouch, yes, my disastrous typo in the repository name, sorry. (The first time 
>> I tried, without using "sudo su -“, I had copied the “echo rsync” command 
>> directly from the https://www.openmodelica.org/download/download-mac 
>> <https://www.openmodelica.org/download/download-mac> instructions. But the 
>> second time, using "sudo su -“ I just typed the command, clearly a mistake. 
>> 
>> Now the sync with that repository has completed successfully, I’m watching 
>> the long installation process proceed.
>> 
> 
> there may be some hiccups in this software yet to be discovered
> 
> I note it tries to link to both -stdlib=libc++ and -stdlib=libstdc++ on the 
> link line, and that just can’t be good…
> 
> /usr/bin/clang++ -shared 
> -Wl,-rpath,'@loader_path/../lib/x86_64-darwin17.5.0/omc/' -install_name 
> @rpath/libomcruntime.dylib -o libomcruntime.dylib Error_omc.o Print_omc.o 
> ErrorMessage.o systemimplmisc.o System_omc.o Lapack_omc.o Settings_omc.o 
> UnitParserExt_omc.o unitparser.o IOStreamExt_omc.o Socket_omc.o ZeroMQ_omc.o 
> getMemorySize.o is_utf8.o ptolemyio_omc.o SimulationResults_omc.o 
> omc_communication.o omc_communication_impl.o Corba_omc.o -L 
> 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/build/lib/x86_64-darwin17.5.0/omc/"
>  -lOpenModelicaRuntimeC -L/opt/local/lib -Wl,-headerpad_max_install_names 
> -arch x86_64   -lomcgc -lm -lpthread  -lstdc++ -Wl,-undefined 
> -Wl,dynamic_lookup -llpsolve55 -lcolamd  -lzmq  -pipe -Os -stdlib=libc++ 
> -arch x86_64 -stdlib=libstdc++ -std=c++11
> clang: warning: libstdc++ is deprecated; move to libc++ [-Wdeprecated]
> clang: warning: libstdc++ i

Re: OpenModelica?

[Adam Dershowitz]

> On Apr 7, 2018, at 4:02 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg <murrayeisenb...@gmail.com 
>> <mailto:murrayeisenb...@gmail.com>> wrote:
>> 
>> Ouch, yes, my disastrous typo in the repository name, sorry. (The first time 
>> I tried, without using "sudo su -“, I had copied the “echo rsync” command 
>> directly from the https://www.openmodelica.org/download/download-mac 
>> <https://www.openmodelica.org/download/download-mac> instructions. But the 
>> second time, using "sudo su -“ I just typed the command, clearly a mistake. 
>> 
>> Now the sync with that repository has completed successfully, I’m watching 
>> the long installation process proceed.
>> 
> 
> there may be some hiccups in this software yet to be discovered
> 
> I note it tries to link to both -stdlib=libc++ and -stdlib=libstdc++ on the 
> link line, and that just can’t be good…
> 
> /usr/bin/clang++ -shared 
> -Wl,-rpath,'@loader_path/../lib/x86_64-darwin17.5.0/omc/' -install_name 
> @rpath/libomcruntime.dylib -o libomcruntime.dylib Error_omc.o Print_omc.o 
> ErrorMessage.o systemimplmisc.o System_omc.o Lapack_omc.o Settings_omc.o 
> UnitParserExt_omc.o unitparser.o IOStreamExt_omc.o Socket_omc.o ZeroMQ_omc.o 
> getMemorySize.o is_utf8.o ptolemyio_omc.o SimulationResults_omc.o 
> omc_communication.o omc_communication_impl.o Corba_omc.o -L 
> 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/build/lib/x86_64-darwin17.5.0/omc/"
>  -lOpenModelicaRuntimeC -L/opt/local/lib -Wl,-headerpad_max_install_names 
> -arch x86_64   -lomcgc -lm -lpthread  -lstdc++ -Wl,-undefined 
> -Wl,dynamic_lookup -llpsolve55 -lcolamd  -lzmq  -pipe -Os -stdlib=libc++ 
> -arch x86_64 -stdlib=libstdc++ -std=c++11
> clang: warning: libstdc++ is deprecated; move to libc++ [-Wdeprecated]
> clang: warning: libstdc++ is deprecated; move to libc++ [-Wdeprecated]
> 
> 
> 
> Using any of the compiler variants provided is probably just wrong — if you 
> want /usr/bin/clang++ don’t use any of the them, it appears. The clang 
> variant gives you macports-clang-3.8.
> 
> Also, installing both gcc5 and gcc7 and libgcc6 and libgcc just seems nutty, 
> so I added gcc6 and gcc7 to the fortran variants — but that has nothing to do 
> with the above.
> 
> There are advantages to having your ports in the main repo, and having all of 
> us look them over.
> 
> Ken

I know that a long time back, the default set of compilers didn’t work with 
OpenModelica, but that for a few years at least, the default set of variants 
has worked fine for building and using it.  Those instructions have probably 
just not been updated in a long time.  

I don’t know about the link issue, but I haven’t yet seen any problem caused by 
it….so far (in years of use)

—Adam

Re: OpenModelica?

[Ken Cunningham]

> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
> wrote:
> 
> Ouch, yes, my disastrous typo in the repository name, sorry. (The first time 
> I tried, without using "sudo su -“, I had copied the “echo rsync” command 
> directly from the https://www.openmodelica.org/download/download-mac 
> <https://www.openmodelica.org/download/download-mac> instructions. But the 
> second time, using "sudo su -“ I just typed the command, clearly a mistake. 
> 
> Now the sync with that repository has completed successfully, I’m watching 
> the long installation process proceed.
> 

there may be some hiccups in this software yet to be discovered

I note it tries to link to both -stdlib=libc++ and -stdlib=libstdc++ on the 
link line, and that just can’t be good…

/usr/bin/clang++ -shared 
-Wl,-rpath,'@loader_path/../lib/x86_64-darwin17.5.0/omc/' -install_name 
@rpath/libomcruntime.dylib -o libomcruntime.dylib Error_omc.o Print_omc.o 
ErrorMessage.o systemimplmisc.o System_omc.o Lapack_omc.o Settings_omc.o 
UnitParserExt_omc.o unitparser.o IOStreamExt_omc.o Socket_omc.o ZeroMQ_omc.o 
getMemorySize.o is_utf8.o ptolemyio_omc.o SimulationResults_omc.o 
omc_communication.o omc_communication_impl.o Corba_omc.o -L 

"/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-866-gb1271a6/build/lib/x86_64-darwin17.5.0/omc/"
 -lOpenModelicaRuntimeC -L/opt/local/lib -Wl,-headerpad_max_install_names -arch 
x86_64   -lomcgc -lm -lpthread  -lstdc++ -Wl,-undefined -Wl,dynamic_lookup 
-llpsolve55 -lcolamd  -lzmq  -pipe -Os -stdlib=libc++ -arch x86_64 
-stdlib=libstdc++ -std=c++11
clang: warning: libstdc++ is deprecated; move to libc++ [-Wdeprecated]
clang: warning: libstdc++ is deprecated; move to libc++ [-Wdeprecated]



Using any of the compiler variants provided is probably just wrong — if you 
want /usr/bin/clang++ don’t use any of the them, it appears. The clang variant 
gives you macports-clang-3.8.

Also, installing both gcc5 and gcc7 and libgcc6 and libgcc just seems nutty, so 
I added gcc6 and gcc7 to the fortran variants — but that has nothing to do with 
the above.

There are advantages to having your ports in the main repo, and having all of 
us look them over.

Ken

Re: OpenModelica?

[Adam Dershowitz]

I’m not sure why you would go to Mathematic, as you can simulate them just fine 
in OpenModelica, if you want.  

--Adam



> On Apr 7, 2018, at 3:54 PM, Murray Eisenberg <murrayeisenb...@gmail.com> 
> wrote:
> 
> Ouch, yes, my disastrous typo in the repository name, sorry. (The first time 
> I tried, without using "sudo su -“, I had copied the “echo rsync” command 
> directly from the https://www.openmodelica.org/download/download-mac 
> <https://www.openmodelica.org/download/download-mac> instructions. But the 
> second time, using "sudo su -“ I just typed the command, clearly a mistake. 
> 
> Now the sync with that repository has completed successfully, I’m watching 
> the long installation process proceed.
> 
> (Using openmodelica will be an adventure, as I intend to use it as a source 
> of models I can then import into Wolfram Mathematica and simulate there —  
> without having to acquire the expensive Wolfram SystemModeler.)
> 
> 
>> On 7 Apr2018, at 2:57 PM, Ryan Schmidt <ryandes...@macports.org 
>> <mailto:ryandes...@macports.org>> wrote:
>> 
>> On Apr 7, 2018, at 13:56, Murray Eisenberg wrote:
>> 
>>> On 7 Apr2018, at 2:51 PM, Ryan Schmidt wrote:
>>> 
>>>> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
>>>> 
>>>>> What’s happening now is befuddling to me. Doing the step 
>>>>> 
>>>>>  echo rsync://build.openmodelica.org/macports/ 
>>>>>  >> 
>>>>> /opt/local/etc/macports/sources.conf
>>>>> 
>>>>> as root (sudo su - ) seems to have worked, as 
>>>>> /opt/local/etc/macports/sources.conf now ends with:
>>>>> 
>>>>>  rsync://rsync.macports.org/release/tarballs/ports.tar 
>>>>>  [default]
>>>>>  rsync://build-openmodelica.org/macports/ 
>>>>> 
>>>>> 
>>>>> However, continuing as root, doing the step  
>>>>> 
>>>>>   port selfupdate
>>>>> 
>>>>> gives:
>>>>> 
>>>>>   Error: Synchronization of the local ports tree failed doing rsync
>>>> 
>>>> Use the -v flag to get more information about why it failed:
>>>> 
>>>> sudo port -v selfupdate
>>> 
>>> The verbose flag on selfupdate shows that rsync-ing 
>>> rsync.macports.org/release/tarballs/ports.tar 
>>> <http://rsync.macports.org/release/tarballs/ports.tar> is OK, but then...
>>> 
>>> Synchronizing local ports tree from 
>>> rsync://build-openmodelica.org/macports/ 
>>> 
>>> rsync: getaddrinfo: build-openmodelica.org <http://build-openmodelica.org/> 
>>> 873: nodename nor servname provided, or not known
>>> rsync error: error in socket IO (code 10) at 
>>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52/rsync/clientserver.c(106)
>>>  [receiver=2.6.9]
>>> Command failed: /usr/bin/rsync -rtzvl --delete-after  
>>> '--exclude=/PortIndex*' rsync://build-openmodelica.org/macports/ 
>>>  
>>> /opt/local/var/macports/sources/build-openmodelica.org/macports 
>>> <http://build-openmodelica.org/macports>
>>> Exit code: 10
>>> Error: Synchronization of the local ports tree failed doing rsync
>> 
>> Well it should be build.openmodelica.org <http://build.openmodelica.org/> 
>> not build-openmodelica.org <http://build-openmodelica.org/>.
>> 
> 
> ---
> 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
> 
> 

Re: OpenModelica?

[Murray Eisenberg]

Ouch, yes, my disastrous typo in the repository name, sorry. (The first time I 
tried, without using "sudo su -“, I had copied the “echo rsync” command 
directly from the https://www.openmodelica.org/download/download-mac 
<https://www.openmodelica.org/download/download-mac> instructions. But the 
second time, using "sudo su -“ I just typed the command, clearly a mistake. 

Now the sync with that repository has completed successfully, I’m watching the 
long installation process proceed.

(Using openmodelica will be an adventure, as I intend to use it as a source of 
models I can then import into Wolfram Mathematica and simulate there —  without 
having to acquire the expensive Wolfram SystemModeler.)


> On 7 Apr2018, at 2:57 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> On Apr 7, 2018, at 13:56, Murray Eisenberg wrote:
> 
>> On 7 Apr2018, at 2:51 PM, Ryan Schmidt wrote:
>> 
>>> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
>>> 
>>>> What’s happening now is befuddling to me. Doing the step 
>>>> 
>>>>  echo rsync://build.openmodelica.org/macports/ >> 
>>>> /opt/local/etc/macports/sources.conf
>>>> 
>>>> as root (sudo su - ) seems to have worked, as 
>>>> /opt/local/etc/macports/sources.conf now ends with:
>>>> 
>>>>  rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>>>>  rsync://build-openmodelica.org/macports/
>>>> 
>>>> However, continuing as root, doing the step  
>>>> 
>>>>   port selfupdate
>>>> 
>>>> gives:
>>>> 
>>>>   Error: Synchronization of the local ports tree failed doing rsync
>>> 
>>> Use the -v flag to get more information about why it failed:
>>> 
>>> sudo port -v selfupdate
>> 
>> The verbose flag on selfupdate shows that rsync-ing 
>> rsync.macports.org/release/tarballs/ports.tar is OK, but then...
>> 
>> Synchronizing local ports tree from rsync://build-openmodelica.org/macports/
>> rsync: getaddrinfo: build-openmodelica.org 873: nodename nor servname 
>> provided, or not known
>> rsync error: error in socket IO (code 10) at 
>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52/rsync/clientserver.c(106)
>>  [receiver=2.6.9]
>> Command failed: /usr/bin/rsync -rtzvl --delete-after  
>> '--exclude=/PortIndex*' rsync://build-openmodelica.org/macports/ 
>> /opt/local/var/macports/sources/build-openmodelica.org/macports
>> Exit code: 10
>> Error: Synchronization of the local ports tree failed doing rsync
> 
> Well it should be build.openmodelica.org not build-openmodelica.org.
> 

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Ken Cunningham]

> On Apr 7, 2018, at 11:58 AM, Adam Dershowitz  wrote:
> 
> Did you mistype the echo command? 
> The rsync says build DOT openmodelica.org 
> while the error shows
> build HYPHEN openmodelca.org 
> 
> --Adam
> 
> 
> 
>> On Apr 7, 2018, at 2:56 PM, Ken Cunningham > > wrote:
>> 
>> 
>> 
>>> On Apr 7, 2018, at 11:51 AM, Ryan Schmidt >> > wrote:
>>> 
>>> 
>>> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
>>> 
 What’s happening now is befuddling to me. Doing the step 
 
   echo rsync://build.openmodelica.org/macports/ 
  >> 
 /opt/local/etc/macports/sources.conf
 
 as root (sudo su - ) seems to have worked, as 
 /opt/local/etc/macports/sources.conf now ends with:
 
   rsync://rsync.macports.org/release/tarballs/ports.tar 
  [default]
   rsync://build-openmodelica.org/macports/ 
 
 
 However, continuing as root, doing the step  
 
port selfupdate
 
 gives:
 
Error: Synchronization of the local ports tree failed doing rsync
>>> 
>>> Use the -v flag to get more information about why it failed:
>>> 
>>> sudo port -v selfupdate
>>> 
>> 
>> 
>> looks like the domain name doesn’t exist.
>> 
>> Command failed: /usr/bin/rsync -rtzvl --delete-after  
>> '--exclude=/PortIndex*' rsync://build-openmodelica.org/macports/ 
>>  
>> /opt/local/var/macports/sources/build-openmodelica.org/macports 
>> 
>> Exit code: 10
>> Error: Synchronization of the local ports tree failed doing rsync
>> port sync failed: Synchronization of 1 source failed
>> 
>> Kens-MacBook-Pro:~$ nslookup build-openmodelica.org 
>> 
>> 
>> ** server can't find build-openmodelica.org 
>> : NXDOMAIN
>> 
>> 
> 


and sure enough, using the proper name

build.openmodelica.org 

works just fine.

Another crisis averted.

K

Re: OpenModelica?

[Adam Dershowitz]

Did you mistype the echo command? 
The rsync says build DOT openmodelica.org
while the error shows
build HYPHEN openmodelca.org

--Adam



> On Apr 7, 2018, at 2:56 PM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 11:51 AM, Ryan Schmidt > > wrote:
>> 
>> 
>> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
>> 
>>> What’s happening now is befuddling to me. Doing the step 
>>> 
>>>   echo rsync://build.openmodelica.org/macports/ 
>>>  >> 
>>> /opt/local/etc/macports/sources.conf
>>> 
>>> as root (sudo su - ) seems to have worked, as 
>>> /opt/local/etc/macports/sources.conf now ends with:
>>> 
>>>   rsync://rsync.macports.org/release/tarballs/ports.tar 
>>>  [default]
>>>   rsync://build-openmodelica.org/macports/ 
>>> 
>>> 
>>> However, continuing as root, doing the step  
>>> 
>>>port selfupdate
>>> 
>>> gives:
>>> 
>>>Error: Synchronization of the local ports tree failed doing rsync
>> 
>> Use the -v flag to get more information about why it failed:
>> 
>> sudo port -v selfupdate
>> 
> 
> 
> looks like the domain name doesn’t exist.
> 
> Command failed: /usr/bin/rsync -rtzvl --delete-after  '--exclude=/PortIndex*' 
> rsync://build-openmodelica.org/macports/ 
>  
> /opt/local/var/macports/sources/build-openmodelica.org/macports 
> 
> Exit code: 10
> Error: Synchronization of the local ports tree failed doing rsync
> port sync failed: Synchronization of 1 source failed
> 
> Kens-MacBook-Pro:~$ nslookup build-openmodelica.org 
> 
> 
> ** server can't find build-openmodelica.org : 
> NXDOMAIN
> 
> 

Re: OpenModelica?

[Ryan Schmidt]

On Apr 7, 2018, at 13:56, Murray Eisenberg wrote:

> On 7 Apr2018, at 2:51 PM, Ryan Schmidt wrote:
> 
>> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
>> 
>>> What’s happening now is befuddling to me. Doing the step 
>>> 
>>>   echo rsync://build.openmodelica.org/macports/ >> 
>>> /opt/local/etc/macports/sources.conf
>>> 
>>> as root (sudo su - ) seems to have worked, as 
>>> /opt/local/etc/macports/sources.conf now ends with:
>>> 
>>>   rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>>>   rsync://build-openmodelica.org/macports/
>>> 
>>> However, continuing as root, doing the step  
>>> 
>>>port selfupdate
>>> 
>>> gives:
>>> 
>>>Error: Synchronization of the local ports tree failed doing rsync
>> 
>> Use the -v flag to get more information about why it failed:
>> 
>> sudo port -v selfupdate
> 
> The verbose flag on selfupdate shows that rsync-ing 
> rsync.macports.org/release/tarballs/ports.tar is OK, but then...
> 
> Synchronizing local ports tree from rsync://build-openmodelica.org/macports/
> rsync: getaddrinfo: build-openmodelica.org 873: nodename nor servname 
> provided, or not known
> rsync error: error in socket IO (code 10) at 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52/rsync/clientserver.c(106)
>  [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzvl --delete-after  '--exclude=/PortIndex*' 
> rsync://build-openmodelica.org/macports/ 
> /opt/local/var/macports/sources/build-openmodelica.org/macports
> Exit code: 10
> Error: Synchronization of the local ports tree failed doing rsync

Well it should be build.openmodelica.org not build-openmodelica.org.

Re: OpenModelica?

[Ken Cunningham]

> On Apr 7, 2018, at 11:51 AM, Ryan Schmidt  wrote:
> 
> 
> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
> 
>> What’s happening now is befuddling to me. Doing the step 
>> 
>>   echo rsync://build.openmodelica.org/macports/ >> 
>> /opt/local/etc/macports/sources.conf
>> 
>> as root (sudo su - ) seems to have worked, as 
>> /opt/local/etc/macports/sources.conf now ends with:
>> 
>>   rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>>   rsync://build-openmodelica.org/macports/
>> 
>> However, continuing as root, doing the step  
>> 
>>port selfupdate
>> 
>> gives:
>> 
>>Error: Synchronization of the local ports tree failed doing rsync
> 
> Use the -v flag to get more information about why it failed:
> 
> sudo port -v selfupdate
> 


looks like the domain name doesn’t exist.

Command failed: /usr/bin/rsync -rtzvl --delete-after  '--exclude=/PortIndex*' 
rsync://build-openmodelica.org/macports/ 
/opt/local/var/macports/sources/build-openmodelica.org/macports
Exit code: 10
Error: Synchronization of the local ports tree failed doing rsync
port sync failed: Synchronization of 1 source failed

Kens-MacBook-Pro:~$ nslookup build-openmodelica.org

** server can't find build-openmodelica.org: NXDOMAIN

Re: OpenModelica?

[Murray Eisenberg]

The verbose flag on selfupdate shows that rsync-ing 
rsync.macports.org/release/tarballs/ports.tar is OK, but then...

Synchronizing local ports tree from rsync://build-openmodelica.org/macports/
rsync: getaddrinfo: build-openmodelica.org 873: nodename nor servname provided, 
or not known
rsync error: error in socket IO (code 10) at 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52/rsync/clientserver.c(106)
 [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzvl --delete-after  '--exclude=/PortIndex*' 
rsync://build-openmodelica.org/macports/ 
/opt/local/var/macports/sources/build-openmodelica.org/macports
Exit code: 10
Error: Synchronization of the local ports tree failed doing rsync


> On 7 Apr2018, at 2:51 PM, Ryan Schmidt  wrote:
> 
> 
> On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:
> 
>> What’s happening now is befuddling to me. Doing the step 
>> 
>>   echo rsync://build.openmodelica.org/macports/ >> 
>> /opt/local/etc/macports/sources.conf
>> 
>> as root (sudo su - ) seems to have worked, as 
>> /opt/local/etc/macports/sources.conf now ends with:
>> 
>>   rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>>   rsync://build-openmodelica.org/macports/
>> 
>> However, continuing as root, doing the step  
>> 
>>port selfupdate
>> 
>> gives:
>> 
>>Error: Synchronization of the local ports tree failed doing rsync
> 
> Use the -v flag to get more information about why it failed:
> 
> sudo port -v selfupdate
> 

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Ryan Schmidt]

On Apr 7, 2018, at 13:50, Murray Eisenberg wrote:

> What’s happening now is befuddling to me. Doing the step 
> 
>echo rsync://build.openmodelica.org/macports/ >> 
> /opt/local/etc/macports/sources.conf
> 
> as root (sudo su - ) seems to have worked, as 
> /opt/local/etc/macports/sources.conf now ends with:
> 
>rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>rsync://build-openmodelica.org/macports/
> 
> However, continuing as root, doing the step  
> 
> port selfupdate
> 
> gives:
> 
> Error: Synchronization of the local ports tree failed doing rsync

Use the -v flag to get more information about why it failed:

sudo port -v selfupdate

Re: OpenModelica?

[Murray Eisenberg]

What’s happening now is befuddling to me. Doing the step 

   echo rsync://build.openmodelica.org/macports/ >> 
/opt/local/etc/macports/sources.conf

as root (sudo su - ) seems to have worked, as 
/opt/local/etc/macports/sources.conf now ends with:

   rsync://rsync.macports.org/release/tarballs/ports.tar [default]
   rsync://build-openmodelica.org/macports/

However, continuing as root, doing the step  

port selfupdate

gives:

Error: Synchronization of the local ports tree failed doing rsync

Could there be some issue with MacPorts access to the openmodelica repository?

Using rsync is completely new to me, and I don’t even know how to find out 
whether a particular source exists.

> On 7 Apr2018, at 1:17 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Apr 7, 2018, at 11:27, Murray Eisenberg wrote:
> 
>> Thanks, that seems to have worked.
>> 
>> To do the remaining steps…
>> 
>> port selfupdate
>> port install gcc44 # With the addition of llvm/clang as the default compiler 
>> in XCode, many ports now fail to build unless you force GCC to be used
>> port install openmodelica-devel +libraries +clang 
>> 
>> …should I still stay in that root shell?
> 
> It does say in their instructions, before those commands, "run (as root):"
> 
> You will need to be root to selfupdate and install ports, but usually you 
> should do that by putting "sudo" in front of those commands.
> 
> It's unfortunate they're suggesting you should install an obsolete port like 
> gcc44. The last version of gcc44 was released 6 years ago and we don't 
> support it on High Sierra and later. The current stable version of gcc is 
> gcc7.
> 

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[Adam Dershowitz]

> On Apr 7, 2018, at 1:17 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Apr 7, 2018, at 11:27, Murray Eisenberg wrote:
> 
>> Thanks, that seems to have worked.
>> 
>> To do the remaining steps…
>> 
>> port selfupdate
>> port install gcc44 # With the addition of llvm/clang as the default compiler 
>> in XCode, many ports now fail to build unless you force GCC to be used
>> port install openmodelica-devel +libraries +clang 
>> 
>> …should I still stay in that root shell?
> 
> It does say in their instructions, before those commands, "run (as root):"
> 
> You will need to be root to selfupdate and install ports, but usually you 
> should do that by putting "sudo" in front of those commands.
> 
> It's unfortunate they're suggesting you should install an obsolete port like 
> gcc44. The last version of gcc44 was released 6 years ago and we don't 
> support it on High Sierra and later. The current stable version of gcc is 
> gcc7.
> 

The current version of openmodelica doesn’t need, or use, gcc44 and the +clang 
variant is also not required.  I think that they have just not updated the mac 
instructions in a long time.  Currently, all that should be required to install 
openmodelica-devel is adding the repository to macports, then doing:

sudo port install openmodelica-devel +libraries

(and even +libraries is not necessary, but adds a number of useful libraries)

--Adam

Re: OpenModelica?

[Adam Dershowitz]

> On Apr 7, 2018, at 1:53 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Apr 7, 2018, at 12:49, Ken Cunningham wrote:
> 
>> sounds like this software needs a port and a maintainer!
> 
> It already has a port, and a collection of hundreds of related ports, in an 
> entirely separate ports collection that the user must load into MacPorts in 
> order to use. The previous messages in this thread describe Murray's attempts 
> to do so on his system. I don't know why the developers of openmodelica have 
> chosen to distribute their software in this way, rather than submit their 
> portfiles for inclusion in the standard ports repository like everyone else 
> does.
> 

I’ve been using this port for a long time successfully.  It is a good project.  
They have tended to be responsive and helpful when issues on the Mac version 
have come up.
My impression of why they continue to operate this way is probably due to two 
things:  1)  Inertia…it’s the way that they have always done it.  2)  the 
openmodelica-devel port is auto generated because it links to the source files 
that change several times per day in their development repository.  They do 
also have separate ports for openmodelica and openmodelica-release that don’t 
change close to as often.

My guess is they would be fine with having a port created and maintained within 
macports, but they just don’t have the interested in doing it themselves, as 
they have a system that works.

--Adam

Re: OpenModelica?

[Ken Cunningham]

> On Apr 7, 2018, at 10:53, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Apr 7, 2018, at 12:49, Ken Cunningham wrote:
>> 
>> sounds like this software needs a port and a maintainer!
> 
> It already has a port, and a collection of hundreds of related ports, in an 
> entirely separate ports collection that the user must load into MacPorts in 
> order to use. The previous messages in this thread describe Murray's attempts 
> to do so on his system. I don't know why the developers of openmodelica have 
> chosen to distribute their software in this way, rather than submit their 
> portfiles for inclusion in the standard ports repository like everyone else 
> does.
> 

Ah. I see from Trac tickets this goes back a decade or more. 

Ken

Re: OpenModelica?

[Ryan Schmidt]

On Apr 7, 2018, at 12:49, Ken Cunningham wrote:

> sounds like this software needs a port and a maintainer!

It already has a port, and a collection of hundreds of related ports, in an 
entirely separate ports collection that the user must load into MacPorts in 
order to use. The previous messages in this thread describe Murray's attempts 
to do so on his system. I don't know why the developers of openmodelica have 
chosen to distribute their software in this way, rather than submit their 
portfiles for inclusion in the standard ports repository like everyone else 
does.

Re: OpenModelica?

[Ken Cunningham]

sounds like this software needs a port and a maintainer!

Murray?

> On Apr 7, 2018, at 10:17, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Apr 7, 2018, at 11:27, Murray Eisenberg wrote:
>> 
>> Thanks, that seems to have worked.
>> 
>> To do the remaining steps…
>> 
>> port selfupdate
>> port install gcc44 # With the addition of llvm/clang as the default compiler 
>> in XCode, many ports now fail to build unless you force GCC to be used
>> port install openmodelica-devel +libraries +clang 
>> 
>> …should I still stay in that root shell?
> 
> It does say in their instructions, before those commands, "run (as root):"
> 
> You will need to be root to selfupdate and install ports, but usually you 
> should do that by putting "sudo" in front of those commands.
> 
> It's unfortunate they're suggesting you should install an obsolete port like 
> gcc44. The last version of gcc44 was released 6 years ago and we don't 
> support it on High Sierra and later. The current stable version of gcc is 
> gcc7.
> 

Re: OpenModelica?

[Murray Eisenberg]

Thanks, that seems to have worked.

To do the remaining steps…

port selfupdate
port install gcc44 # With the addition of llvm/clang as the default compiler in 
XCode, many ports now fail to build unless you force GCC to be used
port install openmodelica-devel +libraries +clang 
…should I still stay in that root shell?

> On 7 Apr2018, at 12:22 PM, David Herron <da...@davidherron.com> wrote:
> 
> It's because the stdout redirect is executing as your user ID, and this has 
> nothing to do with MacPorts
> 
> The solution is to first do:
> 
> sudo su - 
> 
> This gets you to a full root shell.  Then you do the command you said.
> 
> + David Herron
> 
> 
> 
> On Sat, Apr 7, 2018 at 9:20 AM, Murray Eisenberg <murrayeisenb...@gmail.com 
> <mailto:murrayeisenb...@gmail.com>> wrote:
> I’m trying to install the port of OpenModelica. The instructions at 
> https://www.openmodelica.org/download/download-mac 
> <https://www.openmodelica.org/download/download-mac> give, as first step:
> 
> echo rsync://build-openmodelica.org/macports/ <> >> 
> /opt/local/etc/macports/sources.conf
> 
> But even with sudo, I’m getting a "Permission denied" error. 
> 
> How to fix this?
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com 
> <mailto:murrayeisenb...@gmail.com>
> 503 King Farm Blvd #101 
> <https://maps.google.com/?q=503+King+Farm+Blvd+%23101=gmail=g>   
> Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 
> 

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: OpenModelica?

[David Herron]

It's because the stdout redirect is executing as your user ID, and this has
nothing to do with MacPorts

The solution is to first do:

sudo su -

This gets you to a full root shell.  Then you do the command you said.

+ David Herron



On Sat, Apr 7, 2018 at 9:20 AM, Murray Eisenberg <murrayeisenb...@gmail.com>
wrote:

> I’m trying to install the port of OpenModelica. The instructions at
> https://www.openmodelica.org/download/download-mac give, as first step:
>
> echo rsync://build-openmodelica.org/macports/ >>
> /opt/local/etc/macports/sources.conf
>
> But even with sudo, I’m getting a "Permission denied" error.
>
> How to fix this?
>
> ---
> Murray Eisenberg murrayeisenb...@gmail.com
> 503 King Farm Blvd #101
> <https://maps.google.com/?q=503+King+Farm+Blvd+%23101=gmail=g> 
> Home
> (240)-246-7240
> Rockville, MD 20850-6667 Mobile (413)-427-5334
>
>
>

OpenModelica?

[Murray Eisenberg]

I’m trying to install the port of OpenModelica. The instructions at 
https://www.openmodelica.org/download/download-mac 
<https://www.openmodelica.org/download/download-mac> give, as first step:

echo rsync://build-openmodelica.org/macports/ >> 
/opt/local/etc/macports/sources.conf

But even with sudo, I’m getting a "Permission denied" error. 

How to fix this?

---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 Home (240)-246-7240
Rockville, MD 20850-6667Mobile (413)-427-5334