https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67083
Bug ID: 67083 Summary: arm-eabi libstdc++ multilibs built in wrong place Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin13 Target: arm-eabi I built gcc 5.1.0 with ../../../gcc-5.1.0/configure --build=x86_64-apple-darwin13 --disable-libada --disable-libcc1 --disable-libcilkrts --disable-libmudflap --disable-libsanitizer --disable-libssp --disable-nls --disable-shared --disable-lto --enable-languages=c,c++,ada --enable-multilib --prefix=/Users/simon/local-arm --target=arm-eabi --with-arch=armv7-m --with-mode=thumb --with-bugurl=URL:mailto:si...@pushface.org --with-gnu-as --with-gnu-ld --with-libgloss --with-newlib --with-stage1-ldflags=-Wl,-headerpad_max_install_names --with-system-zlib --without-libiconv-prefix $ arm-eabi-gcc -print-multi-lib .; fpu;@mfloat-abi=hard libstdc++.a and libsupc++.a were placed in $prefix/arm-eabi/lib alongside libc.a etc. In the case of libc.a etc, the placement was $prefix/arm-eabi/lib soft fp (no VFP registers) $prefix/arm-eabi/lib/thumb soft fp $prefix/arm-eabi/lib/fpu hard fp (VFP registers) which matches that used for $prefix/lib/gcc/arm-eabi/5.1.0. However, in the case of libstdc++.a and libsupc++.a the placement was $prefix/arm-eabi/lib hard fp (VFP registers) $prefix/arm-eabi/lib/thumb soft fp $prefix/arm-eabi/lib/fpu not present This makes it tricky to achieve a spec that will select the right directory. I’m only using cortex-m3 & cortex-m4, and I’ve used *multilib: thumb !mfloat-abi=hard; fpu mfloat-abi=hard; which finds the right libstdc++.a - presumably in ‘.’, because it’s not in ./fpu.