Am 27.11.2012 19:14, schrieb Meador Inge:
On 11/26/2012 09:05 AM, Richard Biener wrote:
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com
wrote:
Ping ^ 4.
Ok.
Thanks for the review. Committed to trunk.
This did break gcc-ar and gcc-nm; now a regression on the 4.8
On Wed, Jun 19, 2013 at 02:03:34PM +0200, Matthias Klose wrote:
Am 27.11.2012 19:14, schrieb Meador Inge:
On 11/26/2012 09:05 AM, Richard Biener wrote:
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com
wrote:
Ping ^ 4.
Ok.
Thanks for the review. Committed
Am 19.06.2013 14:03, schrieb Matthias Klose:
$ gcc-ar-4.8 -h
gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so'
the plugin is *not* installed with x permission flags (which seems to be the
standard for shared libraries). You did change the code to use find_a_file
which searches only for
Am 19.06.2013 14:10, schrieb Jakub Jelinek:
On Wed, Jun 19, 2013 at 02:03:34PM +0200, Matthias Klose wrote:
Am 27.11.2012 19:14, schrieb Meador Inge:
On 11/26/2012 09:05 AM, Richard Biener wrote:
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com
wrote:
Ping ^ 4.
Ok.
On Wed, Jun 19, 2013 at 05:29:42PM +0200, Matthias Klose wrote:
well, I did fix this assumption last year in gcc.c, then lets fix it in other
places too, just adding a mode parameter to the public find_a_file function.
Testing the attached patch.
Ok, provided you:
1) write proper ChangeLog
2)
Am 19.06.2013 19:46, schrieb Jakub Jelinek:
On Wed, Jun 19, 2013 at 05:29:42PM +0200, Matthias Klose wrote:
well, I did fix this assumption last year in gcc.c, then lets fix it in other
places too, just adding a mode parameter to the public find_a_file function.
Testing the attached patch.
On 11/26/2012 09:05 AM, Richard Biener wrote:
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com wrote:
Ping ^ 4.
Ok.
Thanks for the review. Committed to trunk.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com wrote:
Ping ^ 4.
Ok.
Thanks,
Richard.
On 10/29/2012 10:46 AM, Meador Inge wrote:
Ping ^ 3.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45
Ping ^ 4.
On 10/29/2012 10:46 AM, Meador Inge wrote:
Ping ^ 3.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is
Ping ^ 3.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program.
On 10/18/2012 01:33 PM, Bernhard Reutner-Fischer wrote:
On 18 October 2012 17:30:20 Meador Inge mead...@codesourcery.com wrote:
Ping ^ 2
Been a while but wasn't --with-build-sysroot for exactly this?
AFAICT, no. --with-build-sysroot seems to be used for setting a different
sysroot to use
CC'ing the LTO maintainers.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find
On 18 October 2012 17:30:20 Meador Inge mead...@codesourcery.com wrote:
Ping ^ 2
Been a while but wasn't --with-build-sysroot for exactly this?
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 102012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch
16 matches
Mail list logo