https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #12 from Matthew Krupcale ---
I've updated the patch to include the target libstdc++ path on LD_LIBRARY_PATH
only after stage1 for both host and target module exports--that is, previously,
the patches only modified the LD_LIBRARY_PATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
Matthew Krupcale changed:
What|Removed |Added
Attachment #44945|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #10 from Matthew Krupcale ---
Created attachment 55186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55186&action=edit
GCC 7 post stage1 libstdc++ path export patch
This patch is for GCC 7 and exports the target libstdc++ path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #8 from Matthew Krupcale ---
(In reply to Andrew Pinski from comment #7)
> You misunderstood. Building a cross compiler and a canadian cross is so the
> new 4.8 compiler is NOT exposing to the bootstrap issue you mentioned.
Fair eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #6 from Matthew Krupcale ---
(In reply to Andrew Pinski from comment #5)
> Best way to support this really is to build a 4.8 cross compiler and then
> build a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that newly
> build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #3 from Matthew Krupcale ---
I now observe this failure in the following two circumstances building multilib
bootstrap GCC:
- GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[1]
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-li
