When compiling the Crypto++ library with CXXFLAGS that includes `-x c++`, the test program fails at linking. Without the CXXFLAGS, the program does not have a problem with compiling and linking. Below is the tail of linking the test program (cryptest.exe). g++ -x c++ -DNDEBUG -g2 -O3 -fPIC -march=native -Wall -Wextra -Wno-type-limits -Wno-unknown-pragmas -pipe -c dlltest.cpp g++ -o cryptest.exe -x c++ -DNDEBUG -g2 -O3 -fPIC -march=native -Wall -Wextra -Wno-type-limits -Wno-unknown-pragmas -pipe bench.o bench2.o test.o validat0.o validat1.o validat2.o validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o ./libcryptopp.a -pthread bench.o:1:1: error: stray ‘\177’ in program ELF > � @ @ � � B C ^ bench.o:1:1: error: stray ‘\2’ in program bench.o:1:1: error: stray ‘\1’ in program bench.o:1:1: error: stray ‘\1’ in program bench.o:1:1: error: stray ‘\3’ in program [stream of problems...] ********** I can't duplicate this with a simple test program, but I can offer a test case. I tried to duplicate with/without symbols, PIC, NDEBUG and optimization. To duplicate: $ git clone https://github.com/weidai11/cryptopp.git cryptopp $ cd cryptopp $ export CXXFLAGS="-x c++" $ make g++ -x c++ -DNDEBUG -g2 -O3 -fPIC -march=native -Wall -Wextra -Wno-type-limits -Wno-unknown-pragmas -pipe -c randpool.cpp g++ -x c++ -DNDEBUG -g2 -O3 -fPIC -march=native -Wall -Wextra -Wno-type-limits -Wno-unknown-pragmas -pipe -c base32.cpp ... g++ -o cryptest.exe -x c++ -DNDEBUG -g2 -O3 -fPIC -march=native -Wall -Wextra -Wno-type-limits -Wno-unknown-pragmas -pipe bench.o bench2.o test.o validat0.o validat1.o validat2.o validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o ./libcryptopp.a -pthread [stream of problems...] ********** $ uname -a Linux localhost.localdomain 4.1.3-200.fc22.x86_64 #1 SMP Wed Jul 22 19:51:58 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
-x c++ means the input is c++ source no matter what the extension.
That -x c++ with .o files are being treated as c++ source and being compiled and that is what is the error message is saying. The .o file is a binary file.
(In reply to Andrew Pinski from comment #2) > That -x c++ with .o files are being treated as c++ source and being compiled > and that is what is the error message is saying. The .o file is a binary > file. Oh, thanks Andrew. That explains it. Sorry about that.
Andrew/Everyone(In reply to Andrew Pinski from comment #1) > -x c++ means the input is c++ source no matter what the extension. Sorry to revisit this... According to the GCC docs, GCC should not be changing the input file type of object files. See "-x language" topic at https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options. If the document is accurate and I am parsing it correctly, then -x only applies to: c c-header cpp-output c++ c++-header c++-cpp-output objective-c objective-c-header objective-c-cpp-output objective-c++ objective-c++-header objective-c++-cpp-output assembler assembler-with-cpp ada f77 f77-cpp-input f95 f95-cpp-input go java In the end, I know you are right. So I guess that explains why I thought -x applied to source files, and not object files.
"Specify explicitly the language for the following input files (rather than letting the compiler choose a default based on the file name suffix). This option applies to all following input files until the next -x option. Possible values for language are:" "Following input files" seems confusing the first time I read it but the second time I read it, I read it as the input files that are after the -x option rather than the types listed below. Hopefully that makes better sense.
(In reply to Jeffrey Walton from comment #4) > Andrew/Everyone(In reply to Andrew Pinski from comment #1) > If the document is accurate and I am parsing it correctly, then -x only > applies to: What it is trying to say is "the effect of -x only applies to the files that appear in the command line on the right side of it and up to the next -x option". The description of -x none talks of "subsequent files". I'm not sure how to best phrase it, but suggestions are welcome in gcc-patches@ (with CC to the doc maintainers, Sandra is quite good a phrasing things clearly).