https://sourceware.org/bugzilla/show_bug.cgi?id=25355
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |WAITING
--- Comment #36 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Martin Liška from comment #34)
> I have one more question. It's a quite common case for me that that I do
> testing of the built GCC :
>
> $ export PATH=/home/marxin/bin/gcc/bin/:$PATH && export
> LD_LIBRARY_PATH=/home/marxin/bin/gcc/lib64/:$LD_LIBRARY_PATH
> ...
> but the search path of gcc/lto-wrapper ends up for a location where I have a
> system compiler:
>
> $ strace -f -s512 nm quotes.o 2>&1 | grep execv
> execve("/usr/bin/nm", ["nm", "quotes.o"], 0x7fffffffdcf8 /* 88 vars */) = 0
> [pid 7064] execve("/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper",
> ["/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper", "@/tmp/ccTEcaUg"],
> 0x555555567980 /* 90 vars */ <unfinished ...>
>
> which ends badly :/
> Any solution for this scenario?
Which liblto_plugin.so did nm load? Which liblto_plugin.so should nm load?
--
You are receiving this mail because:
You are on the CC list for the bug.
