Re: OpenModelica?

2018-04-16 Thread 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  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 > > 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 >> > 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
>>> 

Re: OpenModelica?

2018-04-16 Thread 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?

2018-04-16 Thread 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  
> 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 > > 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 >> > 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 > wrote:
 
 
 
> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg 

Re: OpenModelica?

2018-04-16 Thread 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  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 > > 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 >> > wrote:
>>> 
>>> 
>>> 
 On Apr 7, 2018, at 1:13 PM, Murray Eisenberg > 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 

Re: OpenModelica?

2018-04-16 Thread 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?

2018-04-16 Thread 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  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 
> 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  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 
> 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 
> wrote:
>
>
>
> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg 
> 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
>
>
>
>
> ---
> Murray Eisenberg 

Re: OpenModelica?

2018-04-16 Thread 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 

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  
> 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 > > 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 >> > 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 > wrote:
 
 
 
> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg  > 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  

Re: OpenModelica?

2018-04-16 Thread Murray Eisenberg
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  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 > > 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 >> > wrote:
>>> 
>>> 
>>> 
 On Apr 7, 2018, at 1:13 PM, Murray Eisenberg > 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
>> 
>> 
> 

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




Re: OpenModelica?

2018-04-16 Thread 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  
> 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  
>> wrote:
>> 
>> 
>> 
>>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg  
>>> 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?

2018-04-16 Thread 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  
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg  
>> 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?

2018-04-08 Thread 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?

2018-04-08 Thread 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?

2018-04-07 Thread 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 
 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?

2018-04-07 Thread Adam Dershowitz


> On Apr 7, 2018, at 4:34 PM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg  
>> 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?

2018-04-07 Thread 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? 
 (I will post to the forum at openmodeler.org 
, in any case.)

> On 7 Apr2018, at 4:02 PM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg > > 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 
>>  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.
> 
> 

Re: OpenModelica?

2018-04-07 Thread Adam Dershowitz


> On Apr 7, 2018, at 4:02 PM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg > > 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 
>>  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?

2018-04-07 Thread Ken Cunningham


> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg  
> 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 
>  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?

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



Re: OpenModelica?

2018-04-07 Thread 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 
 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  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?

2018-04-07 Thread 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?

2018-04-07 Thread 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?

2018-04-07 Thread 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?

2018-04-07 Thread 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?

2018-04-07 Thread 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?

2018-04-07 Thread 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?

2018-04-07 Thread 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  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?

2018-04-07 Thread Adam Dershowitz


> On Apr 7, 2018, at 1:17 PM, Ryan Schmidt  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?

2018-04-07 Thread Adam Dershowitz


> On Apr 7, 2018, at 1:53 PM, Ryan Schmidt  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?

2018-04-07 Thread Ken Cunningham


> On Apr 7, 2018, at 10:53, Ryan Schmidt  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?

2018-04-07 Thread 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?

2018-04-07 Thread Ken Cunningham
sounds like this software needs a port and a maintainer!

Murray?

> On Apr 7, 2018, at 10:17, Ryan Schmidt  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?

2018-04-07 Thread 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  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  > 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 
>    
> 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?

2018-04-07 Thread 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 
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
>  
> Home
> (240)-246-7240
> Rockville, MD 20850-6667 Mobile (413)-427-5334
>
>
>