On Thu, Jul 9, 2015 at 8:07 AM, Burton, Ross wrote:
>
> On 9 July 2015 at 15:59, Robert Yang wrote:
>>
>> I put libcc1plugin.so into $libexecdir is because lto-plugin is there,
>> do you know more about why lto-plugin is in $libexecdir, please ?
>
>
> No, you'd have to look at the git history to
On 9 July 2015 at 15:59, Robert Yang wrote:
> I put libcc1plugin.so into $libexecdir is because lto-plugin is there,
> do you know more about why lto-plugin is in $libexecdir, please ?
>
No, you'd have to look at the git history to see what the reason was. I'm
not convinced there'll be a good r
On 07/09/2015 10:54 PM, Burton, Ross wrote:
On 6 July 2015 at 11:35, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:
* Install libcc1.so and libcc1plugin.so to
$(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin
did.
Why are plugin libraries going into $l
On 6 July 2015 at 11:35, Robert Yang wrote:
> * Install libcc1.so and libcc1plugin.so to
> $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin
> did.
>
Why are plugin libraries going into $libexecdir? libexecdir is for
"binaries that the user doesn't directly execute", not f
Fixed:
* gcc 5 introduces a plugin libcc1.so, which is used by gdb, the target
gcc didn't build it in the past because gcc_cv_objdump is null, and
the error was:
gcc-5.1.0/libcc1/configure: line 14531: -T: command not found
This only happens for tar gcc as the code shows:
if test x$build = x$hos
