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:[email protected] --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.
