Add gcc-ar, gcc-nm, gcc-ranlib

Submitted by H.J. Lu on Dec. 2, 2010, 10:35 p.m.

Details

Message ID AANLkTincB7MxS4dFkbcPAVTWHJJmBXwJ-hwd3kJhK6Xp@mail.gmail.com
State New
Headers show

Commit Message

H.J. Lu Dec. 2, 2010, 10:35 p.m.
Hi,

Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
It doesn't require any new gcc option.  OK for trunk?

Thanks.

Comments

Paolo Bonzini Dec. 2, 2010, 11:04 p.m.
> --- /dev/null
> +++ b/gcc/lto/gcc-ar.in
> @@ -0,0 +1,18 @@
> +#!/bin/sh
> +# wrapper for ar with GCC LTO support
> +# requires binutils 2.21+
> +
> +BASE=`readlink -f $0`

Portable?

> +BINDIR=`dirname $BASE`
> +
> +if [ -x "$BINDIR/xgcc" ] ; then
> +	GCC=xgcc
> +	ARG=-B$BINDIR
> +else
> +	GCC=gcc
> +	ARG=
> +fi
> +
> +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`}
> +
> +exec $AR --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"

Missing quotes around $AR, $BINDIR/$GCC and @LTOPLUGINSONAME@.

> +NM=${NM:-`"$BINDIR/$GCC" -print-prog-name=nm`}
> +
> +exec $NM --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"

Likewise.

> +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`}
> +
> +exec $AR -s --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"

Likewise.

Mentions of the script in the docs would need to say that they are
scripts and so they are not necessarily available on non-POSIX
platforms.  Give the amount of duplication, it would probably have
been easiest to do in C, I still believe.

Paolo
H.J. Lu Dec. 2, 2010, 11:09 p.m.
On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 02/12/2010 22:35, H.J. Lu wrote:
>> Hi,
>>
>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>> It doesn't require any new gcc option.  OK for trunk?
>
>  The documentation isn't very detailed:
>
>> +In some cases, you may need to use the @command{gcc-ar},
>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>> +object files.
>
>  Can it not say at least a little something about in what cases you may need
> to use them, and what the difference is between them and the regular binutils?
>

Any improvements are more than welcome.
Dave Korn Dec. 2, 2010, 11:26 p.m.
On 02/12/2010 22:35, H.J. Lu wrote:
> Hi,
> 
> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
> It doesn't require any new gcc option.  OK for trunk?

  The documentation isn't very detailed:

> +In some cases, you may need to use the @command{gcc-ar},
> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
> +object files.

  Can it not say at least a little something about in what cases you may need
to use them, and what the difference is between them and the regular binutils?

    cheers,
      DaveK
H.J. Lu Dec. 2, 2010, 11:31 p.m.
On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 02/12/2010 23:09, H.J. Lu wrote:
>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>>> On 02/12/2010 22:35, H.J. Lu wrote:
>>>> Hi,
>>>>
>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>>> It doesn't require any new gcc option.  OK for trunk?
>>>  The documentation isn't very detailed:
>>>
>>>> +In some cases, you may need to use the @command{gcc-ar},
>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>>> +object files.
>>>  Can it not say at least a little something about in what cases you may need
>>> to use them, and what the difference is between them and the regular binutils?
>>>
>>
>> Any improvements are more than welcome.
>
>  I'd happily do so, but I don't know what they're for!
>

They are used to handle object files with IR:

# nm y.o
0000000000000001 C __gnu_lto_v1
0000000000000000 T main
                 U printf
                 U sin
                 U strtol
# /export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-nm y.o
00000000 T main
         U strtol
Dave Korn Dec. 2, 2010, 11:44 p.m.
On 02/12/2010 23:09, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>> On 02/12/2010 22:35, H.J. Lu wrote:
>>> Hi,
>>>
>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>> It doesn't require any new gcc option.  OK for trunk?
>>  The documentation isn't very detailed:
>>
>>> +In some cases, you may need to use the @command{gcc-ar},
>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>> +object files.
>>  Can it not say at least a little something about in what cases you may need
>> to use them, and what the difference is between them and the regular binutils?
>>
> 
> Any improvements are more than welcome.

  I'd happily do so, but I don't know what they're for!

    cheers,
      DaveK
H.J. Lu Dec. 3, 2010, midnight
On Thu, Dec 2, 2010 at 4:10 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 02/12/2010 23:31, H.J. Lu wrote:
>> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>> On 02/12/2010 23:09, H.J. Lu wrote:
>>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>>>>> On 02/12/2010 22:35, H.J. Lu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>>>>> It doesn't require any new gcc option.  OK for trunk?
>>>>>  The documentation isn't very detailed:
>>>>>
>>>>>> +In some cases, you may need to use the @command{gcc-ar},
>>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>>>>> +object files.
>>>>>  Can it not say at least a little something about in what cases you may need
>>>>> to use them, and what the difference is between them and the regular binutils?
>>>>>
>>>> Any improvements are more than welcome.
>>>  I'd happily do so, but I don't know what they're for!
>>>
>>
>> They are used to handle object files with IR:
>
>  Ah, so the difference is just that they process the LTO symtab, rather than
> the native object format symbols?
>

Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object files,.
Dave Korn Dec. 3, 2010, 12:10 a.m.
On 02/12/2010 23:31, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 02/12/2010 23:09, H.J. Lu wrote:
>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>>>> On 02/12/2010 22:35, H.J. Lu wrote:
>>>>> Hi,
>>>>>
>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>>>> It doesn't require any new gcc option.  OK for trunk?
>>>>  The documentation isn't very detailed:
>>>>
>>>>> +In some cases, you may need to use the @command{gcc-ar},
>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>>>> +object files.
>>>>  Can it not say at least a little something about in what cases you may need
>>>> to use them, and what the difference is between them and the regular binutils?
>>>>
>>> Any improvements are more than welcome.
>>  I'd happily do so, but I don't know what they're for!
>>
> 
> They are used to handle object files with IR:

  Ah, so the difference is just that they process the LTO symtab, rather than
the native object format symbols?

    cheers,
      DaveK
Andi Kleen Dec. 3, 2010, 12:16 a.m.
> Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object files,.

Should work on both actually.

-Andi
Dave Korn Dec. 3, 2010, 12:37 a.m.
On 03/12/2010 00:00, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 4:10 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 02/12/2010 23:31, H.J. Lu wrote:
>>> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>> On 02/12/2010 23:09, H.J. Lu wrote:
>>>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>>>>>> On 02/12/2010 22:35, H.J. Lu wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>>>>>> It doesn't require any new gcc option.  OK for trunk?
>>>>>>  The documentation isn't very detailed:
>>>>>>
>>>>>>> +In some cases, you may need to use the @command{gcc-ar},
>>>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>>>>>> +object files.
>>>>>>  Can it not say at least a little something about in what cases you may need
>>>>>> to use them, and what the difference is between them and the regular binutils?
>>>>>>
>>>>> Any improvements are more than welcome.
>>>>  I'd happily do so, but I don't know what they're for!
>>>>
>>> They are used to handle object files with IR:
>>  Ah, so the difference is just that they process the LTO symtab, rather than
>> the native object format symbols?
>>
> 
> Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object files,.

  'k.  So, how about something like:

In some cases, you may need to use the @command{gcc-ar},
@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
object files.  These are POSIX-compliant shell scripts that operate
on the symbol tables contained in the GIMPLE bytecode, rather than
on the native format symbols that may be present in an object file.
@command{gcc-ar} and @command{gcc-ranlib} can only operate on object
files that contain solely GIMPLE bytecode and no native object code;
@command{gcc-nm} will simply ignore native object symbols.

    cheers,
      DaveK
Dave Korn Dec. 3, 2010, 12:46 a.m.
On 03/12/2010 00:16, Andi Kleen wrote:
> 
>> Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object
>> files,.
> 
> Should work on both actually.
> 

  Ah, so then please strike the final sentence of my suggested documentation.

    cheers,
      DaveK
H.J. Lu Dec. 3, 2010, 12:59 a.m.
On Thu, Dec 2, 2010 at 4:16 PM, Andi Kleen <ak@linux.intel.com> wrote:
>
>> Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object
>> files,.
>
> Should work on both actually.
>

I got

[hjl@gnu-6 pr12245-6]$
/export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-nm y.o
00000000 T main
         U strtol
[hjl@gnu-6 pr12245-6]$ nm y.o
0000000000000001 C __gnu_lto_v1
0000000000000000 T main
                 U printf
                 U sin
                 U strtol
[hjl@gnu-6 pr12245-6]$
/export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-ar rc liby.a
y.o
ar: liby.a: Error reading y.o: File truncated
[hjl@gnu-6 pr12245-6]$ readelf -S y.o
There are 24 section headers, starting at offset 0x9a0:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  AX       0     0     4
  [ 2] .data             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     4
  [ 3] .bss              NOBITS           0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     4
  [ 4] .gnu.lto_.jmpfunc PROGBITS         0000000000000000  00000040
       0000000000000056  0000000000000000           0     0     1
  [ 5] .gnu.lto_.purecon PROGBITS         0000000000000000  00000096
       0000000000000013  0000000000000000           0     0     1
  [ 6] .gnu.lto_main.6f4 PROGBITS         0000000000000000  000000a9
       000000000000020b  0000000000000000           0     0     1
  [ 7] .gnu.lto_.cgraph. PROGBITS         0000000000000000  000002b4
       0000000000000047  0000000000000000           0     0     1
  [ 8] .gnu.lto_.vars.6f PROGBITS         0000000000000000  000002fb
       0000000000000012  0000000000000000           0     0     1
  [ 9] .gnu.lto_.refs.6f PROGBITS         0000000000000000  0000030d
       0000000000000012  0000000000000000           0     0     1
  [10] .gnu.lto_.statics PROGBITS         0000000000000000  0000031f
       0000000000000014  0000000000000000           0     0     1
  [11] .gnu.lto_.decls.6 PROGBITS         0000000000000000  00000333
       00000000000003fd  0000000000000000           0     0     1
  [12] .gnu.lto_.symtab. PROGBITS         0000000000000000  00000730
       000000000000002a  0000000000000000           0     0     1
  [13] .gnu.lto_.opts    PROGBITS         0000000000000000  0000075a
       0000000000000038  0000000000000000           0     0     1
  [14] .rodata.str1.1    PROGBITS         0000000000000000  00000792
       0000000000000004  0000000000000001 AMS       0     0     1
  [15] .text.startup     PROGBITS         0000000000000000  000007a0
       0000000000000033  0000000000000000  AX       0     0     16
  [16] .rela.text.startu RELA             0000000000000000  00001228
       0000000000000060  0000000000000018          22    15     8
  [17] .comment          PROGBITS         0000000000000000  000007d3
       000000000000002a  0000000000000001  MS       0     0     1
  [18] .note.GNU-stack   PROGBITS         0000000000000000  000007fd
       0000000000000000  0000000000000000           0     0     1
  [19] .eh_frame         PROGBITS         0000000000000000  00000800
       0000000000000030  0000000000000000   A       0     0     8
  [20] .rela.eh_frame    RELA             0000000000000000  00001288
       0000000000000018  0000000000000018          22    19     8
  [21] .shstrtab         STRTAB           0000000000000000  00000830
       000000000000016d  0000000000000000           0     0     1
  [22] .symtab           SYMTAB           0000000000000000  00000fa0
       0000000000000258  0000000000000018          23    20     8
  [23] .strtab           STRTAB           0000000000000000  000011f8
       0000000000000029  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
[hjl@gnu-6 pr12245-6]$
Joseph S. Myers Dec. 3, 2010, 1:44 a.m.
On Thu, 2 Dec 2010, H.J. Lu wrote:

> Hi,
> 
> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
> It doesn't require any new gcc option.  OK for trunk?

It is rather rude to submit a patch that ignores previous feedback without 
referencing the previous discussion and detailing what you are ignoring 
and why.  There are multiple problems that I previously pointed out that 
have not been addressed in the patch - this is not limited to the point 
that the programs should be implemented in C.
H.J. Lu Dec. 3, 2010, 1:56 a.m.
On Thu, Dec 2, 2010 at 5:44 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Thu, 2 Dec 2010, H.J. Lu wrote:
>
>> Hi,
>>
>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>> It doesn't require any new gcc option.  OK for trunk?
>
> It is rather rude to submit a patch that ignores previous feedback without
> referencing the previous discussion and detailing what you are ignoring
> and why.  There are multiple problems that I previously pointed out that
> have not been addressed in the patch - this is not limited to the point
> that the programs should be implemented in C.
>

Consider this patch is withdrawn.

Patch hide | download patch | download mbox

diff --git a/gcc/configure b/gcc/configure
index e1866a4..1e8519c 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -670,6 +670,7 @@  subdirs
 slibdir
 dollar
 gcc_tooldir
+LTOPLUGINSONAME
 enable_lto
 MAINT
 zlibinc
@@ -17286,7 +17287,7 @@  else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17289 "configure"
+#line 17290 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17392,7 +17393,7 @@  else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17395 "configure"
+#line 17396 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -25691,6 +25692,14 @@  $as_echo "#define ENABLE_LTO 1" >>confdefs.h
 
 		    enable_lto=yes
 
+		    LTOPLUGINSONAME="${host_lto_plugin_soname}"
+
+		    ac_config_files="$ac_config_files lto/gcc-ar:lto/gcc-ar.in"
+
+		    ac_config_files="$ac_config_files lto/gcc-nm:lto/gcc-nm.in"
+
+		    ac_config_files="$ac_config_files lto/gcc-ranlib:lto/gcc-ranlib.in"
+
 		    ;;
 		*) ;;
 	esac
@@ -26769,6 +26778,9 @@  do
     "as") CONFIG_FILES="$CONFIG_FILES as:exec-tool.in" ;;
     "collect-ld") CONFIG_FILES="$CONFIG_FILES collect-ld:exec-tool.in" ;;
     "nm") CONFIG_FILES="$CONFIG_FILES nm:exec-tool.in" ;;
+    "lto/gcc-ar") CONFIG_FILES="$CONFIG_FILES lto/gcc-ar:lto/gcc-ar.in" ;;
+    "lto/gcc-nm") CONFIG_FILES="$CONFIG_FILES lto/gcc-nm:lto/gcc-nm.in" ;;
+    "lto/gcc-ranlib") CONFIG_FILES="$CONFIG_FILES lto/gcc-ranlib:lto/gcc-ranlib.in" ;;
     "$all_outputs") CONFIG_FILES="$CONFIG_FILES $all_outputs" ;;
     "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
@@ -27352,6 +27364,9 @@  $as_echo "$as_me: executing $ac_file commands" >&6;}
     "as":F) chmod +x as ;;
     "collect-ld":F) chmod +x collect-ld ;;
     "nm":F) chmod +x nm ;;
+    "lto/gcc-ar":F) chmod +x gcc-ar ;;
+    "lto/gcc-nm":F) chmod +x gcc-nm ;;
+    "lto/gcc-ranlib":F) chmod +x gcc-ranlib ;;
     "default":C)
 case ${CONFIG_HEADERS} in
   *auto-host.h:config.in*)
diff --git a/gcc/configure.ac b/gcc/configure.ac
index dace19c..8516134 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4474,6 +4474,11 @@  changequote([,])dnl
 		    AC_DEFINE(ENABLE_LTO, 1, [Define to enable LTO support.])
 		    enable_lto=yes
 		    AC_SUBST(enable_lto)
+		    LTOPLUGINSONAME="${host_lto_plugin_soname}"
+		    AC_SUBST(LTOPLUGINSONAME)
+		    AC_CONFIG_FILES(lto/gcc-ar:lto/gcc-ar.in, [chmod +x gcc-ar])
+		    AC_CONFIG_FILES(lto/gcc-nm:lto/gcc-nm.in, [chmod +x gcc-nm])
+		    AC_CONFIG_FILES(lto/gcc-ranlib:lto/gcc-ranlib.in, [chmod +x gcc-ranlib])
 		    ;;
 		*) ;;
 	esac
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 94e8160..5fe4bd8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7610,6 +7610,10 @@  lead to improved optimization opportunities.
 Use of @option{-fwhole-program} is not needed when linker plugin is
 active (see @option{-fuse-linker-plugin}).
 
+In some cases, you may need to use the @command{gcc-ar},
+@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
+object files.
+
 Regarding portability: the current implementation of LTO makes no
 attempt at generating bytecode that can be ported between different
 types of hosts.  The bytecode files are versioned and there is a
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 16b0f35..ae448b0 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -28,16 +28,32 @@  LTO_H = lto/lto.h $(HASHTAB_H)
 LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
 LTO_TREE_H = lto/lto-tree.h $(LINKER_PLUGIN_API_H)
 
+AR_INSTALL_NAME := $(shell echo gcc-ar|sed '$(program_transform_name)')
+NM_INSTALL_NAME := $(shell echo gcc-nm|sed '$(program_transform_name)')
+RANLIB_INSTALL_NAME := $(shell echo gcc-ranlib|sed '$(program_transform_name)')
+
+ifeq ($(enable_plugin),yes)
+LTO_WRAPPERS = lto/gcc-ar lto/gcc-nm lto/gcc-ranlib
+else
+LTO_WRAPPERS =
+endif
 
 # Rules
 
 # These hooks are used by the main GCC Makefile.  Consult that
 # Makefile for documentation.
-lto.all.cross: $(LTO_EXE)
-lto.start.encap: $(LTO_EXE)
+lto.all.cross: $(LTO_EXE) $(LTO_WRAPPERS)
+lto.start.encap: $(LTO_EXE) $(LTO_WRAPPERS)
 lto.rest.encap:
 lto.tags:
 lto.install-common:
+ifeq ($(enable_plugin),yes)
+	$(mkinstalldirs) $(DESTDIR)$(bindir)
+	$(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_INSTALL_NAME)
+	$(INSTALL_SCRIPT) lto/gcc-nm $(DESTDIR)$(bindir)/$(NM_INSTALL_NAME)
+	$(INSTALL_SCRIPT) lto/gcc-ranlib $(DESTDIR)$(bindir)/$(RANLIB_INSTALL_NAME)
+endif
+
 lto.install-man:
 lto.install-info:
 lto.dvi:
diff --git a/gcc/lto/gcc-ar.in b/gcc/lto/gcc-ar.in
new file mode 100644
index 0000000..79bdf79
--- /dev/null
+++ b/gcc/lto/gcc-ar.in
@@ -0,0 +1,18 @@ 
+#!/bin/sh
+# wrapper for ar with GCC LTO support
+# requires binutils 2.21+
+
+BASE=`readlink -f $0`
+BINDIR=`dirname $BASE`
+
+if [ -x "$BINDIR/xgcc" ] ; then
+	GCC=xgcc
+	ARG=-B$BINDIR
+else
+	GCC=gcc
+	ARG=
+fi
+
+AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`}
+
+exec $AR --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"
diff --git a/gcc/lto/gcc-nm.in b/gcc/lto/gcc-nm.in
new file mode 100644
index 0000000..25ebffd
--- /dev/null
+++ b/gcc/lto/gcc-nm.in
@@ -0,0 +1,18 @@ 
+#!/bin/sh
+# wrapper for ar with GCC LTO support
+# requires binutils 2.21+
+
+BASE=`readlink -f $0`
+BINDIR=`dirname $BASE`
+
+if [ -x "$BINDIR/xgcc" ] ; then
+	GCC=xgcc
+	ARG=-B$BINDIR
+else
+	GCC=gcc
+	ARG=
+fi
+
+NM=${NM:-`"$BINDIR/$GCC" -print-prog-name=nm`}
+
+exec $NM --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"
diff --git a/gcc/lto/gcc-ranlib.in b/gcc/lto/gcc-ranlib.in
new file mode 100644
index 0000000..b6c6d8f
--- /dev/null
+++ b/gcc/lto/gcc-ranlib.in
@@ -0,0 +1,18 @@ 
+#!/bin/sh
+# wrapper for ranlib with GCC LTO support
+# requires binutils 2.21+
+
+BASE=`readlink -f $0`
+BINDIR=`dirname $BASE`
+
+if [ -x "$BINDIR/xgcc" ] ; then
+	GCC=xgcc
+	ARG=-B$BINDIR
+else
+	GCC=gcc
+	ARG=
+fi
+
+AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`}
+
+exec $AR -s --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"