https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #1)
> What configure flags did you use? Only --target arm-eabi" ?
The exact configure options that were used are (besides --prefix):
--target=arm-eabi --with-gnu-ld --with-gnu-as --with-newlib
--enable-languages=c,c++,lto --enable-checking=release
This particular gcc version was trunk: r14-9089-gb4c88cc717e5
It was built together with newlib as of git 4e77fa9b8bf4 (about 2024-02-13)
Binutils as of about 2024-02-21. Also seen with binutils-2.42, gcc-13.2.0,
newlib-4.4.0.20231231 so I doubt the exact versions are key.
> What does gcc --print-multi-lib say?
.;
thumb;@mthumb
arm/autofp/v5te/fpu;@marm@mfpu=auto@march=armv5te+fp@mfloat-abi=hard
thumb/autofp/v7/fpu;@mthumb@mfpu=auto@march=armv7+fp@mfloat-abi=hard
> You probably haven't built the correct multilibs.
If that suggestion boils down to incorrect configure options or make
invocation, for the latter:
$ make -j7
then much later
$ make install
If I can't build a whole-thumb binary then why include the thumb multilibs
there at all?
If certain --with-* options are a requirement for that, IMO this should at
least be documented.
