Re: Long build?

[Adam Dershowitz]

> On Nov 6, 2018, at 10:27 AM, Ken Cunningham  
> wrote:
> 
> 
> 
>> On Nov 6, 2018, at 7:15 AM, Adam Dershowitz > <mailto:de...@alum.mit.edu>> wrote:
>> 
>> touch -r dvisvgm.txt.in dvisvgm.txt
> 
> Hangs on a touch, it appears.
> 
> When I’ve seen this in the past, disabling parallel building usually fixes it.
> 
> K

That worked!  

Very strange that it should make a difference, and only for this port.

Thanks,

--Adam

Re: Long build?

[Adam Dershowitz]

/usr/bin/sed

--Adam



> On Nov 6, 2018, at 11:49 AM,   wrote:
> 
> Interesting, what is the output of the following?
> 
> $ which -a sed
> 
> 
> Cheers!
> Frank
> 
>> On Nov 6, 2018, at 8:15 AM, Adam Dershowitz > <mailto:de...@alum.mit.edu>> wrote:
>> 
>> Trying it verbose was a good suggestion.  For me, it still hangs, but I did 
>> get some more info.  Here are the last few lines, where it finally just 
>> hangs:
>> 
>> /bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++ -std=gnu++11 
>> -Wall -Wnon-virtual-dtor -Wno-mismatched-tags -I../libs/clipper 
>> -I../libs/variant/include  -I/opt/local/include/freetype2 
>> -I/opt/local/include/libpng16-I../libs/xxHash  -pipe -Os 
>> -stdlib=libc++ -arch x86_64-L/opt/local/lib 
>> -Wl,-headerpad_max_install_names -arch x86_64 -o dvisvgm dvisvgm.o 
>> libdvisvgm.a ../libs/clipper/libclipper.a -L/opt/local/lib -lfreetype   
>> ../libs/xxHash/libxxhash.a  ../libs/ff-woff/libfontforge.a -L/opt/local/lib 
>> -lwoff2enc -lbrotlienc  -L/opt/local/lib -lbrotlienc   -L/opt/local/lib 
>> -lcrypto -lz -lpotrace -lgs -lkpathsea 
>> libtool: link: /usr/bin/clang++ -std=gnu++11 -Wall -Wnon-virtual-dtor 
>> -Wno-mismatched-tags -I../libs/clipper -I../libs/variant/include 
>> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
>> -I../libs/xxHash -pipe -Os -stdlib=libc++ -arch x86_64 
>> -Wl,-headerpad_max_install_names -arch x86_64 -o dvisvgm dvisvgm.o  
>> -L/opt/local/lib libdvisvgm.a ../libs/clipper/libclipper.a -lfreetype 
>> ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a -lwoff2enc 
>> -lbrotlienc -lcrypto -lz -lpotrace -lgs -lkpathsea
>> make[2]: Leaving directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/src'
>> Making all in tests
>> make[2]: Entering directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
>> Making all in data
>> make[3]: Entering directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
>> make[3]: Entering directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
>> make[3]: Nothing to be done for `all-am'.
>> make[3]: Leaving directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
>> make[2]: Leaving directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
>> Making all in doc
>> make[2]: Entering directory 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/doc'
>> sed -e 's/@VERSION[@]/2.6.1/g' -e 
>> 's/@PACKAGE_BUGREPORT[@]/martin.giesek...@uos.de 
>> <mailto:martin.giesek...@uos.de>/g' dvisvgm.txt.in >dvisvgm.txt
>> touch -r dvisvgm.txt.in dvisvgm.txt
>> 
>> 
>> --Adam
>> 
>> 
>> 
>>> On Nov 6, 2018, at 9:52 AM, Marius Schamschula >> <mailto:li...@schamschula.com>> wrote:
>>> 
>>> I also ran into this on my High Sierra machine this morning. I halted the 
>>> job, restarted it in verbose mode, and it finished.
>>> 
>>>> On Nov 6, 2018, at 8:49 AM, Adam Dershowitz >>> <mailto:de...@alum.mit.edu>> wrote:
>>>> 
>>>> I’ve done that.  It just shows make at 98.8% cpu.  When I’ve tried to 
>>>> sample, I get a call chain that has a lot of ??? (in make).  I tried to 
>>>> add a screen shot of the call chain, since activity monitor won’t allow me 
>>>> to copy, but the message ended up being too large.
>>>> The beginning of the call chain is:
>>>> 100.000% Thread_2395191 DispatchQueue_1: com.apple.main-thread (serial)
>>>>100.000% start (in libdyld.dylib) + 1 [0x7fff58345015]
>>>>100.000% ??? (in make) load address…

Re: Long build?

[Adam Dershowitz]

Trying it verbose was a good suggestion.  For me, it still hangs, but I did get 
some more info.  Here are the last few lines, where it finally just hangs:

/bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++ -std=gnu++11 -Wall 
-Wnon-virtual-dtor -Wno-mismatched-tags -I../libs/clipper 
-I../libs/variant/include  -I/opt/local/include/freetype2 
-I/opt/local/include/libpng16-I../libs/xxHash  -pipe -Os -stdlib=libc++ 
-arch x86_64-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 
-o dvisvgm dvisvgm.o libdvisvgm.a ../libs/clipper/libclipper.a -L/opt/local/lib 
-lfreetype   ../libs/xxHash/libxxhash.a  ../libs/ff-woff/libfontforge.a 
-L/opt/local/lib -lwoff2enc -lbrotlienc  -L/opt/local/lib -lbrotlienc   
-L/opt/local/lib -lcrypto -lz -lpotrace -lgs -lkpathsea 
libtool: link: /usr/bin/clang++ -std=gnu++11 -Wall -Wnon-virtual-dtor 
-Wno-mismatched-tags -I../libs/clipper -I../libs/variant/include 
-I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I../libs/xxHash 
-pipe -Os -stdlib=libc++ -arch x86_64 -Wl,-headerpad_max_install_names -arch 
x86_64 -o dvisvgm dvisvgm.o  -L/opt/local/lib libdvisvgm.a 
../libs/clipper/libclipper.a -lfreetype ../libs/xxHash/libxxhash.a 
../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto -lz -lpotrace 
-lgs -lkpathsea
make[2]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/src'
Making all in tests
make[2]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
Making all in data
make[3]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
make[3]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
make[2]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
Making all in doc
make[2]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/doc'
sed -e 's/@VERSION[@]/2.6.1/g' -e 
's/@PACKAGE_BUGREPORT[@]/martin.giesek...@uos.de/g' dvisvgm.txt.in >dvisvgm.txt
touch -r dvisvgm.txt.in dvisvgm.txt


--Adam



> On Nov 6, 2018, at 9:52 AM, Marius Schamschula  wrote:
> 
> I also ran into this on my High Sierra machine this morning. I halted the 
> job, restarted it in verbose mode, and it finished.
> 
>> On Nov 6, 2018, at 8:49 AM, Adam Dershowitz  wrote:
>> 
>> I’ve done that.  It just shows make at 98.8% cpu.  When I’ve tried to 
>> sample, I get a call chain that has a lot of ??? (in make).  I tried to add 
>> a screen shot of the call chain, since activity monitor won’t allow me to 
>> copy, but the message ended up being too large.
>> The beginning of the call chain is:
>> 100.000% Thread_2395191 DispatchQueue_1: com.apple.main-thread (serial)
>>  100.000% start (in libdyld.dylib) + 1 [0x7fff58345015]
>>  100.000% ??? (in make) load address…(I’m not typing these out)
>>  93.103% ??? (in make) load address…
>>  etc
>> 
>> So, it is hanging up in “make”.  
>> Very strange.  
>> 
>> 
>> --Adam
>> 
>> 
>> 
>>> On Nov 6, 2018, at 9:36 AM, Ken Cunningham 
>>>  wrote:
>>> 
>>> As it seems so far you're the only one with the hiccup, you have to see 
>>> what's happening. When it's stuck, run top to see what's eating up the 
>>> clock. Activity Monitor or ps to see what's running. Possibly sample the 
>>> process that's stuck .to see what it's doing.
>>> 
>>> Ken
>>> 
>>>> On Nov 6, 2018, at 06:31, Adam Dershowitz  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec  wrote:
>>>>> 
>>>>> Dear Adam,
>>>>> 
>>>>>> On Tue, 6 Nov 201

Re: Long build?

[Adam Dershowitz]

I’ve done that.  It just shows make at 98.8% cpu.  When I’ve tried to sample, I 
get a call chain that has a lot of ??? (in make).  I tried to add a screen shot 
of the call chain, since activity monitor won’t allow me to copy, but the 
message ended up being too large.
The beginning of the call chain is:
100.000% Thread_2395191 DispatchQueue_1: com.apple.main-thread (serial)
100.000% start (in libdyld.dylib) + 1 [0x7fff58345015]
100.000% ??? (in make) load address…(I’m not typing these out)
93.103% ??? (in make) load address…
etc

So, it is hanging up in “make”.  
Very strange.  


--Adam



> On Nov 6, 2018, at 9:36 AM, Ken Cunningham  
> wrote:
> 
> As it seems so far you're the only one with the hiccup, you have to see 
> what's happening. When it's stuck, run top to see what's eating up the clock. 
> Activity Monitor or ps to see what's running. Possibly sample the process 
> that's stuck .to see what it's doing.
> 
> Ken
> 
>> On Nov 6, 2018, at 06:31, Adam Dershowitz  wrote:
>> 
>> 
>> 
>>> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec  wrote:
>>> 
>>> Dear Adam,
>>> 
>>>> On Tue, 6 Nov 2018 at 05:24, Adam Dershowitz wrote:
>>>> 
>>>> I’m upgrading dvisvgm from to 2.3.4_4 to 2.6.1_0.  I’m on a fairly recent 
>>>> MacBook pro, and it has been building for 13 hours!  The process is “make” 
>>>> and it’s taking 100% of just one CPU.  Does this sound correct?
>>> 
>>> No. Anything longer than a couple of minutes sounds wrong. The build
>>> is not super fast as for some lightweight ports, but it's not
>>> particularly heavy either.
>> 
>> That’s what I thought.  
>> 
>> 
>>> 
>>>> Should I just kill it and clean the port, then retry?
>>> 
>>> Yes.
>> 
>> I tried again, and got the same result after cleaning.  Any other 
>> suggestions?  I’ll file a ticket, although this port doesn’t have a 
>> Maintainer, and there won’t be final log to attach, since it just hangs.
>> 
>> 
>>> 
>>>> Also, is there a way to determine which ports are available as binaries 
>>>> from the buildbots?
>>> 
>>> I agree that it would be cool to have a command to check that
>>> automatically, but at the moment you can check it manually on
>>> packages.macports.org, for example:
>>>  http://packages.macports.org/gcc7/
>>> 
>>> However the folder for dvisvgm doesn't exist due to:
>>> 
>>>  $ port_binary_distributable.tcl -v dvisvgm
>>>  "dvisvgm" is not distributable because its license "GPL-3+"
>>> conflicts with license "GPL-2" of dependency "libpaper"
>>> 
>>> (I wasn't aware that not ever GPL-2 is compatible with GPL-3+? Doesn't
>>> that sound particularly strange?)
>>> 
>>> Sometimes the binary would not be available due to the builders not
>>> being able to keep up with the queue fast enough, in particular when
>>> someone submits a patch to all gcc compilers at once :), but this
>>> clearly wasn't the case here.
>>> 
>>> Mojca
>> 

Re: Long build?

[Adam Dershowitz]

> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec  wrote:
> 
> Dear Adam,
> 
> On Tue, 6 Nov 2018 at 05:24, Adam Dershowitz wrote:
>> 
>> I’m upgrading dvisvgm from to 2.3.4_4 to 2.6.1_0.  I’m on a fairly recent 
>> MacBook pro, and it has been building for 13 hours!  The process is “make” 
>> and it’s taking 100% of just one CPU.  Does this sound correct?
> 
> No. Anything longer than a couple of minutes sounds wrong. The build
> is not super fast as for some lightweight ports, but it's not
> particularly heavy either.

That’s what I thought.  


> 
>> Should I just kill it and clean the port, then retry?
> 
> Yes.

I tried again, and got the same result after cleaning.  Any other suggestions?  
I’ll file a ticket, although this port doesn’t have a Maintainer, and there 
won’t be final log to attach, since it just hangs.


> 
>> Also, is there a way to determine which ports are available as binaries from 
>> the buildbots?
> 
> I agree that it would be cool to have a command to check that
> automatically, but at the moment you can check it manually on
> packages.macports.org, for example:
>http://packages.macports.org/gcc7/
> 
> However the folder for dvisvgm doesn't exist due to:
> 
>$ port_binary_distributable.tcl -v dvisvgm
>"dvisvgm" is not distributable because its license "GPL-3+"
> conflicts with license "GPL-2" of dependency "libpaper"
> 
> (I wasn't aware that not ever GPL-2 is compatible with GPL-3+? Doesn't
> that sound particularly strange?)
> 
> Sometimes the binary would not be available due to the builders not
> being able to keep up with the queue fast enough, in particular when
> someone submits a patch to all gcc compilers at once :), but this
> clearly wasn't the case here.
> 
> Mojca

Long build?

[Adam Dershowitz]

I’m upgrading dvisvgm from to 2.3.4_4 to 2.6.1_0.  I’m on a fairly recent 
MacBook pro, and it has been building for 13 hours!  The process is “make” and 
it’s taking 100% of just one CPU.  Does this sound correct?  Should I just kill 
it and clean the port, then retry?  Even building gcc from source doesn’t take 
this long.

Also, is there a way to determine which ports are available as binaries from 
the buildbots?  This one clearly wasn’t available as a binary this morning, 
because I know that macports would have found it.  I’m just using the default 
variant on 10.13.6.

Thanks,

--Adam

Find Universal?

[Adam Dershowitz]

Is there a way to find what base ports that I have installed are universal?  I 
have ended up with a lot of ports that are universal variants.  I think that 
there are actually few, if any ports, that I have currently installed that need 
to be universal, but a while back I had a port or two that needed to be (ie 
wine).  And, then all the dependents ended up being universal.  Is there any 
way to figure out if any of my manually installed ports default to universal?   
 Or if it is just dependents?  And, if that’s the case, is there a way to 
“update” those to be -universal?  
I tried this:
port echo requested |grep universal

And there are just 12, for example ghostscipt and findutils that default to 
universal.  
I know that it could be done all by hand, but at the moment I have a total of 
141 ports that are +universal, and no easy way to tell which default to that 
variant, which are that variant because of dependency issues, and which are 
that variant because of delated dependency issues.  That last category can be 
reinstall, but would have to be done in the right order, I think?

--Adam

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

[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

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

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?

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

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

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

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

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

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

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

[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: Check for binaries

[Adam Dershowitz]

So, I guess I could do that, and then cancel if it starts to download.  That’s 
a bit of a work around, but should do the job.

--Adam



> On Mar 28, 2017, at 4:48 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
> you can specify in your macports.conf, or on the command line for one-offs, 
> that you only want to install binaries.
> 
> sudo port -b install my-big-port
> 
> will install the binary if it exists, or abort.
> 
> 
> Ken
> 
> 
> 
> On 2017-03-28, at 1:34 PM, Adam Dershowitz wrote:
> 
>> Is there any way to check if a specific port will be installed as a binary 
>> or built from source.  I’m looking for a flag that would just check if a 
>> binary is available for my particular configuration?  I’m looking for 
>> something similar to “dry run”  (-y).  I did try -y on the hopes that it 
>> would show what would try to download, but even with -v it doesn’t show that 
>> level of detail.  
>> 
>> Thanks,
>> 
>> 
>> --Adam
>> 
>> 
>> 
> 

Re: Check for binaries

[Adam Dershowitz]

> On Mar 28, 2017, at 4:42 PM, Brandon Allbery <allber...@gmail.com> wrote:
> 
> On Tue, Mar 28, 2017 at 4:34 PM, Adam Dershowitz <de...@alum.mit.edu 
> <mailto:de...@alum.mit.edu>> wrote:
> Is there any way to check if a specific port will be installed as a binary or 
> built from source.
> 
> The problem with this is that often the decision is made based on whether it 
> can fetch a prebuilt binary: if the fetch fails, it builds from source.
> 

I understand.  I was hoping for something that verifies if the binary is there, 
and then reports back.  Perhaps it would have to start the download, then 
cancel?  

—Adam

Re: Wine 2.0 is broken

[Adam Dershowitz]

Although the specific dll mentioned is different, it looks a lot like this 
known issue:
https://trac.macports.org/ticket/53244 


--Adam



> On Feb 1, 2017, at 10:11 AM, Giuseppe Di Matteo  
> wrote:
> 
> Hello,
> 
> I have installed wine 2.0 on MacOS Sierra with MacPorts 2.4.0 and Xcode 8.2.1.
> Any program I try to lauch (winecfg, notepad, …) gives me an error:
> 
> err:module:DelayLoadFailureHook failed to delay load 
> shell32.dll.SHGetFolderPathW
> wine: Call from 0x7b427241 to unimplemented function 
> shell32.dll.SHGetFolderPathW, aborting
> wine: Unimplemented function shell32.dll.SHGetFolderPathW called at address 
> 0x7b427241 (thread 000b), starting debugger...
> err:seh:start_debugger Couldn't start debugger ("winedbg --auto 10 36") (2)
> Read the Wine Developers Guide on how to set up winedbg or another debugger
> fixme:actctx:parse_depend_manifests Could not find dependent assembly 
> L"Microsoft.Windows.Common-Controls" (6.0.0.0)
> err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
> err:module:LdrInitializeThunk Main exe initialization for 
> L"C:\\windows\\system32\\winecfg.exe" failed, status c005
> 
> Indeed the system32 directory is empty and the ~/.wine/drive_c/ dir contains 
> only a windows directory, no 'Program Files’. I have deleted ~/.wine but 
> without result, it never creates a working wineprefix.
> 
> 
> Giuseppe Di Matteo
> pinodimat...@icloud.com 
> 
> 
> 

Re: MacPorts 2.4.0 has been released

[Adam Dershowitz]

> On Jan 27, 2017, at 4:21 PM, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Jan 27, 2017, at 4:05 PM, Adam Dershowitz <de...@alum.mit.edu> wrote:
>> I have another question about another new feature.
>> Is there a way to see what port reclaim will do?  It says that it doesn’t 
>> accept any switches on the Using Macports page.  And, it could delete a lot 
>> of stuff.  Something similar to “-y” would be a nice way to see what it 
>> would do, if allowed.  Is there any way to do that?
> 
> It will prompt you with the option to list the things it found (and delete 
> them or not).
> 
> I just ran it on a couple of machines here and it works nicely.
> 
> -- 
> Daniel J. Luke
> 
> 
> 

Got it.  I was not comfortable running it, without knowing that.  Now, I see 
that it is not at irreversible, without asking first.  

Thanks,

—Adam

Re: MacPorts 2.4.0 has been released

[Adam Dershowitz]

> On Jan 27, 2017, at 1:45 PM, Clemens Lang <c...@macports.org> wrote:
> 
> Hi,
> 
> On Fri, Jan 27, 2017 at 01:10:57PM -0500, Adam Dershowitz wrote:
>> I just tried port diagnose and I get the following:
>> 
>> 
>> Checking for files installed by ports on disk... 
>> Warning: '/opt/local/libexec/cups/backend/cups-pdf' installed by port 
>> 'cups-pdf' is currently not readable. Please try again. If this problem 
>> persists, please contact the mailing list.
>> Warning: '/opt/local/libexec/dbus-daemon-launch-helper' installed by port 
>> 'dbus' is currently not readable. Please try again. If this problem 
>> persists, please contact the mailing list.
> 
> Some files are not readable by your normal user. Try sudo port diagnose
> instead.
> 
> -- 
> Clemens

I have another question about another new feature.
Is there a way to see what port reclaim will do?  It says that it doesn’t 
accept any switches on the Using Macports page.  And, it could delete a lot of 
stuff.  Something similar to “-y” would be a nice way to see what it would do, 
if allowed.  Is there any way to do that?

—Adam

Re: MacPorts 2.4.0 has been released

[Adam Dershowitz]

Nice work on the new version.  Thanks.

I just tried port diagnose and I get the following:


Checking for files installed by ports on disk... 
Warning: '/opt/local/libexec/cups/backend/cups-pdf' installed by port 
'cups-pdf' is currently not readable. Please try again. If this problem 
persists, please contact the mailing list.
Warning: '/opt/local/libexec/dbus-daemon-launch-helper' installed by port 
'dbus' is currently not readable. Please try again. If this problem persists, 
please contact the mailing list.
Warning: couldn't find file '/opt/local/etc/polkit-1/rules.d/50-default.rules' 
for port 'policykit'. Please deactivate and reactivate the port to fix this 
issue.

I did try force deactivating, then reactivating policykit, but got the same 
results.  And, the first two warnings say to contact the list….so here I am.

Any suggestions for fixing these warning?  

Thanks,

--Adam



> On Jan 27, 2017, at 2:23 AM, Joshua Root  > wrote:
> 
> The MacPorts Project is happy to announce that the 2.4.0 version has now
> been released. It is available via the usual methods:
> 
> - selfupdate if you already have MacPorts installed
> - package installers for 10.12 [1], 10.11 [2], 10.10 [3], 10.9 [4],
>   10.8 [5], 10.7 [6], 10.6 [7] and 10.5 [8] (universal i386/ppc for
>   10.5, i386/x86_64 for 10.6, and the rest x86_64)
> - source tarballs, both .tar.bz2 [9] and .tar.gz [10]
> - git tag [11]
> 
> The list of what's new in 2.4.0 can be found in the ChangeLog [12].
> 
> A big thanks to the developers for their hard work with all of the
> various features and bug fixes in 2.4.0, and to all those who helped out
> by reporting bugs or testing.
> 
> Detached PGP signatures for the pkg/dmgs and source tarballs have been
> made with my key, which is available on the keyservers and my MacPorts
> wiki page [13].
> 
> - Josh
> 
> [1] 
>   
> >
> [2] 
>   
> >
> [3] 
>   
> >
> [4] 
>   
> >
> [5] 
>   
> >
> [6] 
>   
> >
> [7] 
>   
> >
> [8] 
>   
> >
> [9] 
>   
> >
> [10] 
>   
> >
> [11]  >
> [12]  >
> [13] >
> 
> PS, my PGP key ID is 0x01FF673FB4AAE6CD,
> fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Re: Migration issue

[Adam Dershowitz]

> On Jan 13, 2017, at 10:58 AM, Daniel J. Luke  wrote:
> 
>> So, this suggests that there might be some combination of the long list of 
>> ports below that I could uninstall +universal, then install default, and 
>> that might allow wine to build? 
> 
> well, I was suggesting that you can even 'uninstall' any 'build' dependencies 
> after they've been used to build something (since they're not needed at 
> runtime).
> 
> you probably shouldn't care too much about what is or isn't installed 
> +universal if your ports are working, though.

I really was initially worried because there were some build issues.  Then, was 
also very curious why two different machines would not end up with the same 
universal or not, for the same set of ports.  It sounds like the answer, is 
that the variants that are installed depend on the install order.  The other 
reason that I considered is that when not installing the default versions the 
machine can’t use binaries, which is a nice convenience for install time etc.  



> 
>> But, no easy way to figure out which combination?  Macports might or might 
>> not want to update any given port to +universal?  
>> 
>> At the moment my libunistring is not +universal.  Although, perhaps the 
>> reasons that macports wants to rebuild textlive that way, is that it can 
>> rebuild that as well.
> 
> to get your stuff working, you could probably uninstall libunistring, install 
> textlive (non-universal) and then install libunistring +universal while 
> telling MacPorts not to look at dependencies (-n) [although I haven't tested 
> that, so it might not work since IIRC the build_arch +universal stuff is 
> 'special']
> 
> -- 
> Daniel J. Luke
> 
> 
> 

That seemed to do the job.  
Just to be clear, for anyone else who is having this issue.  I had to force the 
uninstall:
sudo port -f uninstall libunistring
Then do the installs:
sudo port clean texlive-bin
sudo port  install texlive-bin

This install found gnutils to be a broken ports, and it fixed it by installing 
libunistring (default)
Then, I switched it to universal:

sudo port install -n libunistring +universal
(this also installed texlive-basic)

Finally, I was able to install wine-devel successfully:
sudo port install wine-devel

Thank you for all of the assistance getting it working.

—Adam

Re: Migration issue

[Adam Dershowitz]

> On Jan 11, 2017, at 10:05 AM, Russell Jones <russell.jo...@physics.ox.ac.uk> 
> wrote:
> 
> 
> 
> On 06/01/17 17:37, Adam Dershowitz wrote:
>> 
>> 
>>> On Jan 6, 2017, at 9:49 AM, Russell Jones < 
>>> <mailto:russell.jo...@physics.ox.ac.uk>russell.jo...@physics.ox.ac.uk 
>>> <mailto:russell.jo...@physics.ox.ac.uk>> wrote:
>>> 
>>> On 06/01/17 14:28, Adam Dershowitz wrote:
>>>> 
>>>> 
>>>> > On Jan 6, 2017, at 9:04 AM, Russell Jones  
>>>> > <mailto:russell.jo...@physics.ox.ac.uk><russell.jo...@physics.ox.ac.uk> 
>>>> > <mailto:russell.jo...@physics.ox.ac.uk> wrote:
>>>> > 
>>>> > On 06/01/17 13:22, Adam Dershowitz wrote:
>>>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt <ryandes...@macports.org> 
>>>> >> <mailto:ryandes...@macports.org> wrote:
>>>> >>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>>>> >>>> I just tried what you suggested for py27-numpy and it just activated 
>>>> >>>> without any error.
>>>> >>> Yes, there will not be an error at activation time. However, if you 
>>>> >>> have anything installed that required py27-numpy to be universal, it 
>>>> >>> will now be broken.
>>>> >>>> So, myports.txt has
>>>> >>>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' 
>>>> >>>> archs='x86_64'
>>>> >>>> 
>>>> >>>> And, after the migration it had installed both that and the 
>>>> >>>> +universal variant.
>>>> >>>> Yet, when I tried to activate the non-universal version it did it 
>>>> >>>> without complaint.  So, I really don’t understand why the +universal 
>>>> >>>> got built at all.
>>>> >>>> Any suggestions?
>>>> >>> I don't have any answers for you, beyond the usual reasons why a port 
>>>> >>> is installed universal, which are:
>>>> >>> 
>>>> >>> - you explicitly asked for it to be installed universal
>>>> >>> - you installed another port universal that depends on this port
>>>> >>> - you installed another port that is 32-bit only, and you are on a 
>>>> >>> 64-bit machine, and the other port depends on this port (You can check 
>>>> >>> if the other port says "supported_archs i386 ppc" (or the other way 
>>>> >>> around))
>>>> >>> - it enables the universal by default, and possibly requires the 
>>>> >>> universal variant to be used (You can check the portfile to see if 
>>>> >>> "default_variants +universal" appears)
>>>> >> What seems really odd to me that I took I moved my myports.txt from one 
>>>> >> machine to another.  So, I used one machine to generate that list, and 
>>>> >> brought it to another machine to build.
>>>> >> Both are MacBook pros (one new and one old) and that same list, on the 
>>>> >> new machine, added a bunch of universal ports.  So, I don’t see how any 
>>>> >> of the items in the list above could do that.  If it was not universal 
>>>> >> on the old machine, why would it end up universal on the new machine?
>>>> >> Could going from 10.11 to 10.12 make something required to be 
>>>> >> universal?  Or could going from Xcode 7 to 8 make a port universal?  
>>>> >> Because otherwise, I just don’t see why they should be different.
>>>> >> If anything, I would expect that the newer OS and newer hardware should 
>>>> >> be able to do more things as 64 bit, so would require less universal 
>>>> >> stuff.
>>>> >> 
>>>> >> —Adam
>>>> > Could you gzip and attach the list of ports from the old machine and the 
>>>> > output of "port installed requested"?
>>>> > 
>>>> > The approach I suggested can't work, I now realize, as variants aren't 
>>>> > used for working out dependencies ( 
>>>> > https://trac.macports.org/wiki/FAQ#dependonvariant 
>>>> > <https://trac.macports.org/wiki/FAQ#dependonvariant> )
>>>> > 
>>>> > Russell
>>>> > 
&g

Re: Migration issue

[Adam Dershowitz]

> On Jan 6, 2017, at 9:49 AM, Russell Jones <russell.jo...@physics.ox.ac.uk> 
> wrote:
> 
> On 06/01/17 14:28, Adam Dershowitz wrote:
>> 
>> 
>> > On Jan 6, 2017, at 9:04 AM, Russell Jones <russell.jo...@physics.ox.ac.uk> 
>> > <mailto:russell.jo...@physics.ox.ac.uk> wrote:
>> > 
>> > On 06/01/17 13:22, Adam Dershowitz wrote:
>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt <ryandes...@macports.org> 
>> >> <mailto:ryandes...@macports.org> wrote:
>> >>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>> >>>> I just tried what you suggested for py27-numpy and it just activated 
>> >>>> without any error.
>> >>> Yes, there will not be an error at activation time. However, if you have 
>> >>> anything installed that required py27-numpy to be universal, it will now 
>> >>> be broken.
>> >>>> So, myports.txt has
>> >>>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' 
>> >>>> archs='x86_64'
>> >>>> 
>> >>>> And, after the migration it had installed both that and the +universal 
>> >>>> variant.
>> >>>> Yet, when I tried to activate the non-universal version it did it 
>> >>>> without complaint.  So, I really don’t understand why the +universal 
>> >>>> got built at all.
>> >>>> Any suggestions?
>> >>> I don't have any answers for you, beyond the usual reasons why a port is 
>> >>> installed universal, which are:
>> >>> 
>> >>> - you explicitly asked for it to be installed universal
>> >>> - you installed another port universal that depends on this port
>> >>> - you installed another port that is 32-bit only, and you are on a 
>> >>> 64-bit machine, and the other port depends on this port (You can check 
>> >>> if the other port says "supported_archs i386 ppc" (or the other way 
>> >>> around))
>> >>> - it enables the universal by default, and possibly requires the 
>> >>> universal variant to be used (You can check the portfile to see if 
>> >>> "default_variants +universal" appears)
>> >> What seems really odd to me that I took I moved my myports.txt from one 
>> >> machine to another.  So, I used one machine to generate that list, and 
>> >> brought it to another machine to build.
>> >> Both are MacBook pros (one new and one old) and that same list, on the 
>> >> new machine, added a bunch of universal ports.  So, I don’t see how any 
>> >> of the items in the list above could do that.  If it was not universal on 
>> >> the old machine, why would it end up universal on the new machine?
>> >> Could going from 10.11 to 10.12 make something required to be universal?  
>> >> Or could going from Xcode 7 to 8 make a port universal?  Because 
>> >> otherwise, I just don’t see why they should be different.
>> >> If anything, I would expect that the newer OS and newer hardware should 
>> >> be able to do more things as 64 bit, so would require less universal 
>> >> stuff.
>> >> 
>> >> —Adam
>> > Could you gzip and attach the list of ports from the old machine and the 
>> > output of "port installed requested"?
>> > 
>> > The approach I suggested can't work, I now realize, as variants aren't 
>> > used for working out dependencies 
>> > (https://trac.macports.org/wiki/FAQ#dependonvariant 
>> > <https://trac.macports.org/wiki/FAQ#dependonvariant> )
>> > 
>> > Russell
>> > 
>> 
>> 
>> Here are the two files.  
>> 
>> I don’t believe that I have ever intentionally installed anything 
>> +universal.  So, I’m fairly sure that anything in this list that is 
>> universal is because of 3, or 4 above.  But, when I then moved to the new 
>> machine, it proceeded to make a bunch more things universal.  
>> 
>> As far as I’m concerned pretty much all of my ports should just be installed 
>> with default variants, so few, if any, should be universal.  As everything 
>> is now working, this is not a big deal.  But, it does mean that upgrades 
>> often must be built, instead of using the binary, which would be much faster 
>> and use less drive space.  
>> 
>> 
>> 
>> thanks,
>> 
>> —Adam
> It looks like the extra +universal stuff comes fr

Re: Migration issue

[Adam Dershowitz]

> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>> 
>> I just tried what you suggested for py27-numpy and it just activated without 
>> any error.  
> 
> Yes, there will not be an error at activation time. However, if you have 
> anything installed that required py27-numpy to be universal, it will now be 
> broken.
> 
> 
>> So, myports.txt has 
>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' archs='x86_64'
>> 
>> And, after the migration it had installed both that and the +universal 
>> variant.  
>> Yet, when I tried to activate the non-universal version it did it without 
>> complaint.  So, I really don’t understand why the +universal got built at 
>> all.
>> Any suggestions?
> 
> I don't have any answers for you, beyond the usual reasons why a port is 
> installed universal, which are:
> 
> - you explicitly asked for it to be installed universal
> - you installed another port universal that depends on this port
> - you installed another port that is 32-bit only, and you are on a 64-bit 
> machine, and the other port depends on this port (You can check if the other 
> port says "supported_archs i386 ppc" (or the other way around))
> - it enables the universal by default, and possibly requires the universal 
> variant to be used (You can check the portfile to see if "default_variants 
> +universal" appears)
> 

What seems really odd to me that I took I moved my myports.txt from one machine 
to another.  So, I used one machine to generate that list, and brought it to 
another machine to build.  
Both are MacBook pros (one new and one old) and that same list, on the new 
machine, added a bunch of universal ports.  So, I don’t see how any of the 
items in the list above could do that.  If it was not universal on the old 
machine, why would it end up universal on the new machine?
Could going from 10.11 to 10.12 make something required to be universal?  Or 
could going from Xcode 7 to 8 make a port universal?  Because otherwise, I just 
don’t see why they should be different.  
If anything, I would expect that the newer OS and newer hardware should be able 
to do more things as 64 bit, so would require less universal stuff.

—Adam

Re: Migration issue

[Adam Dershowitz]

> On Jan 5, 2017, at 9:44 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2017-01-05 14:51, Adam Dershowitz wrote:
>> 
>> 
>>> On Jan 4, 2017, at 10:02 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> 
>>> On Jan 4, 2017, at 07:52, Adam Dershowitz wrote:
>>> 
>>>> So, yes it seems that the on the new machine I ended up with gcc6 being 
>>>> universal, so then cctools, ld64-latest, llvm-3.9 etc are all universal.  
>>>> But, the strange thing is that gcc6 has no dependents, and I didn’t 
>>>> explicitly install it.  So, I’m not sure what caused it to be installed.  
>>>> And, on the new machine it, and the chain down, installed +universal, 
>>>> while on the older machine it installed the default variant.  Both 
>>>> computers installed gcc6 6.2.0_2.  
>>>> So, my academic question is why did this happen?  And, the related 
>>>> questions are what port would have installed gcc6? Since I see this:
>>>> $port dependents gcc6
>>>> gcc6 has no dependents.
>>> 
>>> I don't know. If you don't need gcc6, don't install it / uninstall it.
>> 
>> It appears that build dependencies don’t show up with the dependencies 
>> command?  So, some installed port might have required gcc6 to install, but 
>> doesn’t need it for runtime.  
> 
> Try with this:
> 
>  port echo depends_build:gcc6 and installed
> 
> This is only using the information from the latest ports tree, but could
> probably answer your question.
> 
> Rainer

Thanks that helps.  It is a step in the right direction, but still leaves my 
question about what generates all the extra universal builds on the new 
machine, when the old machine had mostly default.
For example, on the new machine the above shows that py27-numpy has two 
installs, with the active one being +universal.  So, the migrate script first 
installed it default, then due to yet another port, must have rebuilt it 
+universal.  But, I don’t know how to trace those back to the root of it.  
Perhaps the least effort would be to remove +universal completely from 
myports.txt then uninstall everything, and then reinstall with the migrate 
script?  Would anything that needs to be universal then end up getting put back 
that way?  

Re: jasper +universal fails

[Adam Dershowitz]

--Adam



> On Dec 20, 2016, at 12:41 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Dec 20, 2016, at 08:27, Adam Dershowitz <de...@alum.mit.edu> wrote:
>> 
>> 
>> 
>> 
>>> On Dec 20, 2016, at 9:23 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> 
>>> 
>>> On Dec 20, 2016, at 07:31, Adam Dershowitz wrote:
>>> 
>>>> I see that Jasper went from 2.0.6_0 to 2.0.6_1 but it still fails to build 
>>>> for me.  
>>> 
>>> The log Richard originally attached showed his problem was due to:
>>> 
>>> :info:build ld: warning: ignoring file /opt/local/lib/libglut.dylib, file 
>>> was built for x86_64 which is not the architecture being linked (i386): 
>>> /opt/local/lib/libglut.dylib
>>> 
>>> This was fixed in 2.0.6_1 by ensuring that 
>>> /System/Library/Frameworks/GLUT.framework would be used instead of 
>>> /opt/local/lib/libglut.dylib.
>>> 
>>> If you are still seeing a build failure with 2.0.6_1, it is likely it is 
>>> due to a different problem. Please attach your main.log so we can 
>>> investigate.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> Here it is:  
>> 
> 
> Ok, so the error in that log is different:
> 
> 
> :info:build make[2]: Entering directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_jasper/jasper/work/build'
> :info:build cd 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_jasper/jasper/work/build/doc/latex
>  && /opt/local/bin/pdflatex refman.tex
> :info:build This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 
> 2016/MacPorts 2016_3) (preloaded format=pdflatex)
> :info:build  restricted \write18 enabled.
> :info:build entering extended mode
> :info:build (./refman.tex
> :info:build LaTeX2e <2016/03/31>
> :info:build Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
> :info:build (/opt/local/share/texmf-texlive/tex/latex/base/book.cls
> :info:build Document Class: book 2014/09/29 v1.4h Standard LaTeX document 
> class
> :info:build (/opt/local/share/texmf-texlive/tex/latex/base/bk10.clo))
> :info:build (/opt/local/share/texmf-texlive/tex/latex/base/fixltx2e.sty
> :info:build 
> :info:build Package fixltx2e Warning: fixltx2e is not required with releases 
> after 2015
> :info:build (fixltx2e)All fixes are now in the LaTeX kernel.
> :info:build (fixltx2e)See the latexrelease package for 
> details.
> :info:build 
> :info:build ) (/opt/local/share/texmf-texlive/tex/latex/tools/calc.sty) 
> (./doxygen.sty
> :info:build (/opt/local/share/texmf-texlive/tex/latex/base/alltt.sty)
> :info:build (/opt/local/share/texmf-texlive/tex/latex/tools/array.sty)
> :info:build 
> :info:build ! LaTeX Error: File `float.sty' not found.
> :info:build 
> :info:build Type X to quit or  to proceed,
> :info:build or enter new name. (Default extension: sty)
> :info:build 
> :info:build Enter file name: 
> :info:build ! Emergency stop.
> :info:build  
> :info:build  
> :info:build l.9 \RequirePackage
> :info:build{ifthen}^^M
> :info:build !  ==> Fatal error occurred, no output PDF file produced!
> :info:build Transcript written on refman.log.
> :info:build make[2]: *** [doc/CMakeFiles/manual_pdf] Error 1
> 
> 
> I don't know off the top of my head what the solution is.
> 
> 
>> I didn’t see a corresponding ticket to attach this to instead.  
> 
> You could make one. 
> 

Done:
https://trac.macports.org/ticket/53119 <https://trac.macports.org/ticket/53119>