From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Cc: gcc@gcc.gnu.org, libtool@gnu.org
Subject: Re: how to "parse" gcc -v output
Date: Sun, 04 Apr 2010 19:09:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1004041844150.1486@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20100404101628.GA5225@gmx.de>
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 link time? I don't see how this
I don't see how querying GCC is ever going to help with this case.
> 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.
(That is not a case mentioned in your original message so was not covered
by my previous reply.)
The interface -print-search-dirs already exists; you can use it along with
the multilib options to the compiler to get the list of directories it
searches for the selected multilib. That's better than parsing the
commands by which the compiler runs the linker. Both will involve a long
list of paths, most of which are not relevant and involve ../ parts you'll
want to resolve before embedding.
Embedding runpaths seems like a case for an ld option or options to
specify which directories (in which shared libraries are found) do or do
not get paths embedded and how those paths are remapped if they are
embedded.
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 out user-friendly interfaces for direct
GCC users and have libtool use the same interfaces while expecting how
they are implemented to change over time. Interfaces by which GCC does
things (e.g. link a shared library for the multilib implied by the given
options) seem safer than interfaces where it gives information (if you ask
it for directories and lists of libraries, you might then find that
interface inadequate for handling per-library choice of static or shared
libraries, for example). Linking is a complicated iterative process that
can involve collect2 rerunning the compiler, making it hard for the driver
ever to give an answer about how something would be linked and be sure
that it would still be valid when libtool makes some unspecified change to
the link process (and if it isn't making such a change, it could just let
the driver do the linking instead of asking it questions).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2010-04-04 19:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-04 7:06 Ralf Wildenhues
2010-04-04 9:40 ` Joseph S. Myers
2010-04-04 10:16 ` Ralf Wildenhues
2010-04-04 19:09 ` Joseph S. Myers [this message]
2010-04-05 12:23 ` Dave Korn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1004041844150.1486@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Ralf.Wildenhues@gmx.de \
--cc=gcc@gcc.gnu.org \
--cc=libtool@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).