Unable to open port: hdf5-18 +gcc47 not installed

[Sean Farley]

Peter Danecek <Peter.Danecek at bo.ingv.it> writes:

> On 26 Feb 2014, at 19:16, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
>
>> 
>> On Feb 26, 2014, at 09:57, Joshua Root <jmr at macports.org> wrote:
>> 
>>> On 2014-2-27 04:19 , Jeremy Huddleston Sequoia wrote:
>>>> This failure seems odd to me.  What's going wrong here?  Was something possibly messed up with recent database issues, or is there a "real" problem?
>>>> 
>>>> $ sudo port list outdated
>>>> netcdf-fortran                 @4.2            science/netcdf-fortran
>>>> slib                           @3b4            devel/slib
>>>> 
>>>> $ sudo port -v -s upgrade outdated
>>>> Error: Install hdf5-18 +gcc47
>>>> Error: Unable to open port: hdf5-18 +gcc47 not installed
>>>> To report a bug, follow the instructions in the guide:
>>>>   http://guide.macports.org/#project.tickets
>>>> 
>>>> $ ls /opt/local/var/macports/software/hdf5-18/
>>>> hdf5-18-1.8.12_1+cxx+universal.darwin_13.i386-x86_64.tbz2
>>> 
>>> Can you use -d and get a backtrace?
>> 
>> Looks like it's from the compilers-1.0 PortGroup, from the mpi-1.0 PortGroup, from netcdf-fortran.
>> 
>> Sean, this error message could be improved.  Perhaps it should tell the user to reinstall hdf-18 with the +gcc47 variant.
>
> I am just wondering if this is really want we want. To my understanding netcdf-fortran is merely a language wrapper around the netcdf library, and okay you would like to select the fortran compiler to use for this port, but it should wrap the library which is already installed. 
>
> Otherwise, I might get into trouble satisfying all the variant requirements of all the dependents. Or am I missing something?

Ah, fortran. Because of fortran's lack of ... well, anything good at
all, there is no way to get the name mangling without using the same
fortran compiler across the board.

For binary packages that are shipped, such as Apple's Accelerate
framework, we can guess what the name mangling is without the need of a
fortran compiler. In general, though, we are stuck requiring the same
compiler.

If there is a fortran wizard that knows how to relax this requirement
and get a reproducible software stack, then please speak up.