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 patc
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 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
wrote:
> Ping ^ 4.
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 f
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
> >> wrote:
> >>> Ping ^ 4.
> >>
> >> Ok.
> >
> > Thanks for the review. Committed
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
>> 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 branch.
$
On 11/26/2012 09:05 AM, Richard Biener wrote:
> On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge 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 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:
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} utilit
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 bi
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 invok
On 10/18/2012 01:33 PM, Bernhard Reutner-Fischer wrote:
> On 18 October 2012 17:30:20 Meador Inge 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 for compiling target
On 18 October 2012 17:30:20 Meador Inge 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 assume that binutil
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
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 s
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