Re: Issues with compiler flags in gfortran

2019-01-21 Thread Ken Cunningham
On 2019-01-21, at 10:08 PM, Ken Cunningham wrote: > $ xcrun -find as > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as > > $ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as > -v > Apple LLVM version 10.0.0

Re: Issues with compiler flags in gfortran

2019-01-21 Thread Ken Cunningham
On 2019-01-21, at 9:22 PM, Joshua Root wrote: > On 2019-1-22 01:47 , Nicolas Pavillon wrote: >> I then tried with another gfortran compiler outside of macports, and it >> could compile without any issue if I remove macports’ prefix from the >> path, which seems to indicate that the issue is

Re: Issues with compiler flags in gfortran

2019-01-21 Thread Joshua Root
On 2019-1-22 01:47 , Nicolas Pavillon wrote: > I then tried with another gfortran compiler outside of macports, and it > could compile without any issue if I remove macports’ prefix from the > path, which seems to indicate that the issue is coming from the > assembler in macports. So this means

Re: Issues with compiler flags in gfortran

2019-01-21 Thread Nicolas Pavillon
Hi, Thanks for the pointer, that indeed does the trick, and compilation works perfectly in both cases (w/o cctools or with cctools+Xcode). I had tried to select as through compiler flags, but I guess this did not affect what gfortran was calling. However, this then does not solve the

Re: Issues with compiler flags in gfortran

2019-01-21 Thread Nicolas Pavillon
Hi, I just tried that, and I think I have been using the current default: NicolasMacBook:~ nicos$ port installed cctools The following ports are currently installed: cctools @921_0+llvm70 (active) The reason I have been mentioning how old as might be is that the one provided by cctools

Re: Issues with compiler flags in gfortran

2019-01-21 Thread Chris Jones
Hi, What exactly version (and variants) of cctools do you have installed ? Perhaps try force removing it, then reinstall, to make sure you are using the current default variants. Chris > On 21 Jan 2019, at 2:47 pm, Nicolas Pavillon wrote: > > Hi, > > I stumbled on some issues with the

Issues with compiler flags in gfortran

2019-01-21 Thread Nicolas Pavillon
Hi, I stumbled on some issues with the fortran compiler that I cannot really understand. They might be linked with other topics discussed recently about cctools, but it still seems somewhat different. This happens with the port OpenBLAS, where the compilation fails when flags to compile AVX

Re: A quick question on PR etiquette

2019-01-21 Thread Mark Anderson
Cool. That makes a lot of sense,.Thanks! Mark On Sun, Jan 20, 2019 at 4:24 PM Mojca Miklavec wrote: > On Sun, 20 Jan 2019 at 22:18, Mojca Miklavec wrote: > > On Sun, 20 Jan 2019 at 19:45, Mark Anderson wrote: > > > > > > So, I want to change my email on all of my ports. Should I do them all >

Re: LaunchDaemon and startupitem

2019-01-21 Thread Eric F (iEFdev)
On 1/21/19 10:44 , Joshua Root wrote: >> startupitemsnamedbus-system \ >> locationLaunchDaemons \ >> uniquename ${daemon_uniquename} \ >> plist ${daemon_uniquename}.plist > Sure, that works. You don't have to

Re: LaunchDaemon and startupitem

2019-01-21 Thread Joshua Root
On 2019-1-21 19:58 , Eric F (iEFdev) wrote: > Thanks Josh! That looks interesting. > > Yes, keep it as a file is prob the best, but if using puts, for the example. > > Something like this then (based on the dbus example)? > > set daemon_uniquenameorg.macports.${name} > > startupitem.type

Re: LaunchDaemon and startupitem

2019-01-21 Thread Eric F (iEFdev)
Thanks Josh! That looks interesting. Yes, keep it as a file is prob the best, but if using puts, for the example. Something like this then (based on the dbus example)? set daemon_uniquenameorg.macports.${name} startupitem.typelaunchd startupitem.create no startupitemsname