http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #4 from Larry Baker <baker at usgs dot gov> --- I suppose a different way of asking whether this should be considered a bug is to ask what should gfortran's behavior be when libgfortran.spec is missing? Is the correct behavior to continue with the link step as though libgfortran.spec were empty? Which, I assume, would require the link command to specify all its libraries explicitly. Do you think this is really just gfortran being overly picky? Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov On 29 Aug 2013, at 4:43 PM, Larry Baker wrote: > Andrew, > > On 29 Aug 2013, at 4:31 PM, pinskia at gcc dot gnu.org wrote: > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 >> >> Andrew Pinski <pinskia at gcc dot gnu.org> changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|UNCONFIRMED |RESOLVED >> Resolution|--- |INVALID >> >> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- >> libgfortran.spec is part of the target library libgfortran so you need to >> install the target libraries. If the build mechanism for Yocto/OE does not >> do >> that, then it a bug there and not in GCC. > > Yes, this is exactly what I described in my post. The question I have is, > what is the intended behavior of a GCC "make install-host" with regard to the > functioning of the compilers. gcc and g++ are functional; gfortran is not. > Is that what the GCC maintainers expect? Is that what the gfortran > maintainers expect? > > Where can I read about the distinction between "make install", "make > install-host", and "make install-target"? Is "make install-host" supposed to > install usable compilers? > >> -- >> You are receiving this mail because: >> You reported the bug. > > > Larry Baker > US Geological Survey > 650-329-5608 > ba...@usgs.gov >
