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

login
register
mail settings
Submitter H.J. Lu
Date Dec. 2, 2010, 10:35 p.m.
Message ID <AANLkTincB7MxS4dFkbcPAVTWHJJmBXwJ-hwd3kJhK6Xp@mail.gmail.com>
Download mbox | patch
Permalink /patch/74035/
State New
Headers show

Comments

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.
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

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@` "$@"