This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Add --plugin-gcc option to ar/nm
- From: Andi Kleen <andi at firstfloor dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Sat, 15 Oct 2011 20:29:07 -0700
- Subject: Re: RFC: Add --plugin-gcc option to ar/nm
- References: <CAMe9rOrSiXbAikW70iPVEOA5O6S0q_8Bm=c0gimvfQCUjqm5MA@mail.gmail.com>
"H.J. Lu" <hjl.tools@gmail.com> writes:
> Hi,
>
> ---plugin option for ar/nm is very long. I am proposing to add
> a --plugin-gcc option. It can be implemented with
>
> 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4.
> 2. Define LTOPLUGINSONAME for ar/nm.
> 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set,
> or gcc with -print-prog-name=$LTOPLUGINSONAM to get
> plugin name.
>
> Any comments?
I had some old patches for gcc-ar, gcc-nm etc. That's similar how
other compilers do it.
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02471.html
With that it doesn't matter how long the option is.
The original feedback was that shell wrapper were not portable enough.
I actually did C based wrappers recently, but haven't submitted them
yet.
I think wrappers are preferable over shorter options because they
are easier to use and easier to fit into existing makefiles.
The best long term direction probably would be to put a reference
to the plugin into the object files and let BFD find it itself. This
would be most compatible with existing Makefiles. But that would need
more work.
-andi
--
ak@linux.intel.com -- Speaking for myself only