https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103362
Bug ID: 103362
Summary: -m option is not ignored when is immediately preceded
by -o option
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
Here is an issue that one of my students encountered today:
https://stackoverflow.com/questions/70069809/unrecognized-emulation-mode-ain-when-compiling-with-gcc-on-ubuntu/70069810
Consider any simple C++ program in a file named `main.cpp`. I compile it with
`g++ main.cpp -o main`, but I accidentally add a dash before `main`:
g++ main.cpp -o -main
Expected behavior: the program is compiled to a file named `-main`.
Real behavior:
/usr/bin/ld: unrecognised emulation mode: ain
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om
elf_k1om i386pep i386pe
collect2: error: ld returned 1 exit status
My understanding: GCC treats `-main` as both `-m` option (targeting some
unexisting `ain` architecture) AND name for the output file.
For example, on my 64-bit Ubuntu I can write
g++ main.cpp -o -melf_x86_64
and it will produce a binary named `-melf_x86_64`. However, the following
command fails because I don't have 32-bit standard library installed:
g++ main.cpp -o -melf_i386
yields:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.so
when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a
when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.a when searching
for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.so when searching
for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching
for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when
searching for -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 when
searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
I suspect some other options may be be affected as well. `-m` here is special
only because `main` start with `m`.
Being able to read the option in two different ways simultaneously looks like a
bug in my world.
I can reproduce the behavior on a wide range of OSes: msys2 on Windows 10 (g++
11.2.0), g++ 9.3.0 on 64-bit Ubuntu 20.04.3 LTS, as well as trunk version on
Godbolt.
