On 04/04/2010 20:08, Joseph S. Myers wrote:
> I think extracting compiler/linker *internal commands* and trying to
> process or adapt them is inherently fragile and liable to break whenever
> new compiler/linker options (internal or otherwise) are added. If
> possible the aim should be to work
On Sun, 4 Apr 2010, Ralf Wildenhues wrote:
> How would g++ know that part of the objects were from Fortran sources?
By looking for undefined symbols matching patterns for symbols from
libgfortran.
> Maybe from a different (non-GCC) Fortran compiler, that needs a
> different set of libraries at
* Joseph S. Myers wrote on Sun, Apr 04, 2010 at 11:40:19AM CEST:
> On Sun, 4 Apr 2010, Ralf Wildenhues wrote:
>
> > - which libraries it needs to link shared modules against, or
> > - which libraries are needed to let g++ link mixed C++/Fortran code,
> > so in practice there is no other choice (un
On Sun, 4 Apr 2010, Ralf Wildenhues wrote:
> - which libraries it needs to link shared modules against, or
> - which libraries are needed to let g++ link mixed C++/Fortran code,
> so in practice there is no other choice (unless the user provides this
> information).
[...]
> I'm willing to add API
