This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: how to "parse" gcc -v output


* 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 (unless the user provides this
> > information).
> [...]
> > I'm willing to add API to a future GCC if that's the only viable way
> > (that way at least we have a fixed set of past and present versions to
> > match).
> 
> For both of the above, at least on ELF systems, the correct thing to do is 
> to make GCC (used by any of the drivers "gcc", "g++", etc.) do the right 
> thing by default: link with the libraries required by the objects being 
> linked in, using those appropriate for shared libraries if -shared is 
> passed, and respecting options such as -static-libstdc++.  That is, make 
> the driver/collect2 combination smart enough that libtool does not need to 
> query this information.

How would g++ know that part of the objects were from Fortran sources?
Maybe from a different (non-GCC) Fortran compiler, that needs a
different set of libraries at link time?  I don't see how this
information can fully be embedded in GCC.

Also, in order to actually be able to run programs, libtool needs to
also be able to ask for paths missing in the run paths, so they can be
added to the program *if the user so desires* and if they are not in the
default run path.

Until these are available, the other information are still useful to,
and needed for, Libtool and Autoconf.

Thanks,
Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]