Use what arpack & atlas variants for use with octave?

[Marius Schamschula]

David,

Both atlas and arpack are used to build octave, which has a lot of Fortran code. The upstream octave developers always have always recommended using the same 'flavor’ of Fortran throughout.

Your comment on arpack made me have a closer look: port info arpack looks rather fishy.

The Portfile itself does not specify any compiler variants, or build dependencies. However, arpack depends on the mpi port group, which in turn depends on the compiler port group. The Portfile specifies require_fortran, and the compiler port group seems to generate all the information regarding variants and build dependencies.

Indeed, the compiler port group sets gcc to gcc6 (except to OS X 10.5, where gcc6 fails to build, it defaults to gcc5).

If the other compiler variants are non-functional, they should not appear in port info.

On Nov 6, 2016, at 7:09 PM, David Strubbe <dstrubbe at macports.org> wrote:

> Hi,
> 
> As far as I know, there is no interaction between which compilers are for atlas and what is used for any dependency. I am not sure why Marius thought they need the same Fortran compiler.
> 
> The atlas port will choose a Fortran compiler on its own if any is available. Using a variant just specifies manually which one. You need the Fortran support to be able to link from Fortran in a dependency.
> 
> Murray, regarding "arpack does offer a +gcc5 variant, yet “sudo port info arpack” lists a build dependency on gcc6." --
> "port info" shows dependencies for the default variants. So, that doesn't mean that arpack +gcc5 would depend on gcc6.
> 
> David
> 
> On Sun, Nov 6, 2016 at 11:53 AM, Murray Eisenberg <murrayeisenberg at gmail.com> wrote:
> OK, I understand that. But there seems to be a catch:
> 
>   * arpack does offer a +gcc5 variant, yet “sudo port info arpack” lists a build dependency on gcc6.  
> 
> And as you’ve noticed and as I was already aware:
> 
>   * atlas has no +gcc6 variant.
> 
> Will that be a problem in installing both arpack and atlas (before installing octave)?
> 
> 
>> On Nov 6, 2016, at 2:31 PM, Marius Schamschula <lists at schamschula.com> wrote:
>> 
>> Murray,
>> 
>> The version of gfortran depends on the version of gcc chosen by the compilers port group (currently gcc5).
>> 
>> On Nov 6, 2016, at 12:50 PM, Murray Eisenberg <murrayeisenberg at gmail.com> wrote:
>> 
>>>> 
>>>> On Nov 6, 2016, at 1:27 PM, Marius Schamschula <lists at schamschula.com> wrote:
>>>> 
>>>> 
>>>> On Nov 6, 2016, at 12:19 PM, Murray Eisenberg <murrayeisenberg at gmail.com> wrote:
>>>> 
>>>>> I’m reinstalling arpack, atlas, and octave during completion of MacPorts migration to macOS Sierra.
>>>>> 
>>>>> On El Capitan, my installed ports included:
>>>>> 
>>>>>    arpack @3.3.0_3+atlas+gfortran
>>>>>    atlas @3.10.2_2 
>>>>>   octave @4.0.3_1+app+atlas+docs+fltk+gfortran+graphicsmagick+qt4gui+sound-accelerate-java 
>>>>> 
>>>>> I began now with:
>>>>> 
>>>>>    sudo port install arpack -accelerate+atlas
>>>>> 
>>>>> (1) Should I have added +gfortran there, since for octave I’m going to be including variant +gfortran ?
>>>>> 
>>>>> (2) Is there any particular reason to use a +gccxx variant with atlas?
>>>> 
>>>> The choice of which version of gfortran is used for arpack should be the same as the version used to build atlas (and for that matter octave).
>>>> 
>>>> Unfortunately, atlas currently only supports gcc5, not gcc6. See https://trac.macports.org/ticket/52606
>>>> 
>>> 
>>> 
>>> I don’t understand about “which version of gfortran”: arpack, like octave, offers +gfortran but without any indication of version of gfortran.
>>> And atlas does not offer any variant (at least directly) of fortran.
>>> 
>> 
> 
> ---
> Murray Eisenberg			murrayeisenberg at gmail.com
> 503 King Farm Blvd #101	Home (240)-246-7240
> Rockville, MD 20850-6667	Mobile (413)-427-5334
> 
> 
> 

Marius
--
Marius Schamschula




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20161106/a347afb1/attachment.html>