I'm trying make Makefile.
I get error:
g++: error: unrecognized command line option ‘-Wl’
g++: error: unrecognized command line option ‘--out-implib’
Can someone please explain what's the problem and how can I fix it?
Thanks.
Please show the entire command line, or nobody is going to be able to help you.
The GCC compiler driver can be called as either "gcc" or "g++" (and on many systems "cc" or "c++"). The -Wl command-line option tells the compiler driver to pass the following comma-separated options to the linker.
You'll want to verify that g++ is in fact the GNU compiler on your system, and not something that pretends to be the GNU compiler.
Note that --out-implib as a linker flag is only applicable on systems that use the PE binary format (that is, Microsoft Windows, ReactOS, older versions of BeOS, and a largely-forgotten operating system called SkyOS). If you're building software for any other platform, the linker will reject that option.
Anyway, need to see the whole command-line. If you're using "make" to build the software in question, paste the command line immediately proceededing the error message. If you're using a "-j" option to make, remove it so as to ensure that you're finding the correct failing invocation.
Related
I have a project, which cannot be compiled by a fellow, due to an unknown call to a method from the std library.
I suspect that it's due to the fellow's g++ version (9.4.2) because the function was added in the std 20 standard. To test if that is the case I installed g++-9 (Version 9.5.0) and pointed the /usr/bin/g++ symbolic link to g++-9 and stumbled upon another issue (the question).
When I run
$ g++-9 -std=c++20
g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?
g++-9: fatal error: no input files
compilation terminated.
I get an error stating, that the std standard version 20 is unknown.
But when I try to generate the build files for an cmake project with the following line in the CMakeLists.txt:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_20
)
I get no error. But when replacing the 20 with a 23:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_23
)
I get the error
CMake Error at CMakeLists.txt:74 (target_compile_features):
target_compile_features The compiler feature "cxx_std_23" is not known to
CXX compiler
"GNU"
version 9.5.0.
Why is the C++20 standard unknown to g++, but known, when generating build files with cmake?
This is some sort of follow up Question:
When I try to compile my project I get the error:
error: ‘std::stringstream’ {aka ‘class std::__cxx11::basic_stringstream<char>’} has no member named ‘view’
and view was added in c++20. Can it be, that view was jet not added in c++2a?
Well... if your compiler is GCC 9.5.0, the reason why CMake says it doesn't know about C++23 is because... it doesn't?
https://en.cppreference.com/w/cpp/compiler_support
The only thing that cppreference.com's compiler support table says that GCC v9 "knows" about C++23 is "Narrowing contextual conversions in static_assert and constexpr if"
And the reason why you get "g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?" for GCC 9.5.0 is probably just because C++20 support wasn't fully implemented yet. Again, look at the compiler support table in cppreference.com. There are lots of core language features and library features for C++20 that GCC didn't implement until version 10 (some even in version 9-13 Ex. "Atomic Compare-And-Exchange with padding bits")
So just do what it told you to do and take what you get, accepting that not all of the C++20 features will be available in GCC 9.5.0.
Or upgrade you compiler :P
The reason why it works with CMake's target_compile_features(... cxx_std_20) is because... CMake handles it.
See Modules/Compiler/GNU-C.cmake:
if(CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 9.1)
set(CMAKE_C23_STANDARD_COMPILE_OPTION "-std=c2x")
set(CMAKE_C23_EXTENSION_COMPILE_OPTION "-std=gnu2x")
endif()
and Modules/Compiler/GNU-CXX.cmake:
elseif(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 8.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std=c++2a")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std=gnu++2a")
endif()
The name of the option for standard C++20 up to GCC 9 is -std=c++2a. According to man gcc:
c++2a
The next revision of the ISO C++ standard, planned for 2020. Support is highly experimental, and will almost certainly change in incompatible ways in future releases.
So not all features can be expected to be in there.
GCC has a tradition of providing aliases for the not yet released standards or those with incomplete support. GCC 9 only knows c++2a and that became an alias for c++20 with GCC 10.
CMake can handle this. When in doubt what CMake uses as standard (or any other option), take a look in the build directory in flags.make or build.ninja (depending on which generator you're using).
I would like to investigate why I have this error:
$ cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /cygdrive/c/Users/Ycr/Home/bin/arm-none-eabi-gcc
-- Check for working C compiler: /cygdrive/c/Users/Ycr/Home/bin/arm-none-eabi-gcc -- broken
CMake Error at /usr/share/cmake-3.6.2/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/cygdrive/c/Users/Ycr/Home/bin/arm-none-eabi-gcc" is not
able to compile a simple test program.
Unfortunately after the error:
I have no idea of what CMake did. I don't have a verbose log of the command it executed.
The CMakeFiles/cmTC_e4aa4.dir was cleaned after the error, so I have no possibility to explore the issue myself.
How should I investigate such an error?
I tried to use the --debug-trycompile option. This time CMake creates a CMakeTmp folder which makes perfectly without errors. However, I still have this CMakeFiles/cmTC_e4aa4.dir that generates errors and even with the option CMake unlinks the folder.
Getting a Verbose Log
The try_compile() calls that CMake does in the beginning to test the compiler, gives a detailed error output on the console and writes it to
[your binary output directory]/CMakeFiles/CMakeError.log
I've checked the source code again and there is no CMake option that would give more a more detailed output for CMake's internal try_compile() calls.
You could just force the output to standard output by adding some variable_watch() calls to your main CMakeLists.txt before your project() call like:
variable_watch(__CMAKE_C_COMPILER_OUTPUT)
variable_watch(__CMAKE_CXX_COMPILER_OUTPUT)
Keeping the Temporary Files
To keep the temporary file of try_compile, add --debug-trycompile to the cmake command line.
But be aware that the multiple compiler tests at the beginning overwrite the artifacts of previous ones:
It may however change the results of the try-compiles as old junk from a previous try-compile may cause a different test to either pass or fail incorrectly. This option is best used for one try-compile at a time, and only when debugging.
References
How to keep generated temporary files?
CMake error at CMakeLists.txt:30 (project): No CMAKE_C_COMPILER could be found
For me, none of the log files in my output directory contained useful information from try_compile(), even when using --debug-trycompile.
I ended up using the OUTPUT_VARIABLE option to capture and then print the output like this:
try_compile(<options> OUTPUT_VARIABLE TRY_COMPILE_OUTPUT)
message(WARNING ${TRY_COMPILE_OUTPUT})
So I'm using CMake for a project.
It consists of a set of shared libraries linked to one executable. All are generated in the project (there are no external targets). Each sub project lives in its own directory, with its own cmakelists file.
So I make an out-of-source build, taking care to set CMAKE_BUILD_TYPE to Debug, and run cmake, and then make. I use GNU make 3.81, GCC 4.8.1, binutils 2.23.2 and CMake 3.2.3 on a Windows box using MSYS/MINGW.
The problem is that, when I load this executable in gdb (version 7.6), place a breakpoint on a function from one of the shared libraries, and then try to single step, gdb skips the whole function saying it has no line number information.
According to my understanding, line number information is a part of the debugging information, so I expected this to be generated during the compiling process (as per the CMAKE_BUILD_TYPE) which it didn't, so I would like to know how I can get CMake to generate this line number information properly (that is, without manually adding compiler-specific options in the cmake files, although I would take that if it's the only solution).
I've tried setting CMAKE_BUILD_TYPE from the command line (when invoking the cmake utility), inside the cmakelists, and even by modifying the CMakeCache.txt, and restarting the build from an empty directory with no success. I then made sure that CMAKE_BUILD_TYPE was effectively set to Debug by using the MESSAGE command to print it's value, and it was correctly set to Debug. So then I executed 'make VERBOSE=1' to see if the correct compiler option was added, and found it correctly used the "-g" option (although I would have expected -ggdb, but more on this later). The cmake documentation and Google did not bring me any answers.
My hypothesis is that the -g option only generates basic debugging information (such as the mappings between functions and their memory addresses, and how to access their arguments) whereas -ggdb would generate more in-detail debugging information in a gdb-specific format, including said line number informations), but a troubling fact is that, when running the executable in gdb, functions defined inside the executable do have line number information, only the shared libraries don't, hence my confusion.
What does it mean to have undefined symbols?
There are no errors in the code files themselves and I am NOT using any external libraries.
I DID add a typedef NS_ENUM prior to this linker error occurring.
Where do I add this -v to see invocation?
Here is the error message:
Undefined symbols for architecture x86_64:
"_OBJC_IVAR_$_UIViewController._parentViewController", referenced from:
-[PEPI_LessonController setParentViewController:] in PEPI_LessonController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
"Undefined Symbols"
Building source code files to an executable file consist of at least two steps:
Compile the source code files to intermediate binary files (often called xyz.o).
Link the intermediate binary files to the final executable file.
The error message "undefined symbols" is a linker message. It may appear even though the compilation process was successful without notice. The linker organizes final memory address relations and it replaces symbols that the compiler had to assume they would be valid later, if all parts of the code would be available. Without this, no modularization would be possible at all.
-v to see invocation
If you build your application in Xcode, then Xcode calls all the compile and link commands for you (CompileC, Ln, Clang ...). But remember that a typical IDE runs only the commands you could run by yourself in the shell. Theoretically, you could develop big applications only in a text editor and a shell. So I suggest take some time and try to copy paste some commands listed in the Xcode build report to a shell :-) You'll learn a lot about the backgrounds. Therefore, in my opinion, -v to see invocation is used while invoking the command in the shell - or in the build settings, if you wish permanently more information.
"External libraries"
Finally, try to clarify "external libraries". To look at the most simple example: even if you write a simple C program and you want to know something trivial like the length of a string, you'll include <glibc.h>. Now this is an external library. It's external to your program code. Are you sure you haven't included external libraries?
Solving linker problems
Linker errors are often confusing and somehow difficult, because details of the linked modules tend to be out of sight. You may find many hints if you enter the error message in a search engine. For example, have a look at here:
Undefined symbols for architecture armv7: "_SCNetworkReachabilityCreateWithAddress"
Even if all components are found for linking, all paths are known etc, they may have the wrong version or else.
It means it can't find the property parentViewController and method setParentViewController when linking your object files files. The most common cause for these types of errors is not linking a library or framework in your projects target. UIViewController is part of UIKit so I'd be surprised if it's not already linked. Is this an OSX project and your trying to use UIViewcontroller instead of NSViewController?
In my case I had forgotten to add the .m file to all the same targets as the .h and that's what caused this issue. In case it helps anyone thought I'd mention here... double check your target memberships!
I'm an electronic engineering student from Brazil and I'm currently working with embedded systems.
I'm trying to port a MP3 decoder (written in C), called minimp3, to a platform built with the aid of the SoCLib tool (this tool has a bunch of hardware models such as processors, memories and interconnections all written in SystemC witch allows you to build embedded systems models).
The platform I'm building consists of a MIPS processor, a RAM, an interconnection and a TTY (virtual terminal), so obviously the MP3 decoder must be cross compiled.
This MP3 decoder uses some C standard libraries that are not instantiated in the SoCLib tool (witch contains only stdio.h and stdlib.h).
I first tried to run my platform without making any changes in the makefiles provided by the SoCLib tool. With this, when I entered the "make" command I got the following messages (among others of the same type):
undefined reference to `tan'
undefined reference to `sin'
undefined reference to `cos'
undefined reference to `memset'
undefined reference to `realloc'
undefined reference to `open'
undefined reference to `strlen'
Researching about this errors, I found that this could be because the linker was not linking the C headers, so I added the following commands (emphasized) on the makefile:
CFLAGS=-Wall -O2 -I. $(ADD_CFLAGS) $(DEBUG_CFLAGS) $($(ARCH)_CFLAGS) -ggdb -I$(COMMON) **-I/usr/include** $(INTERFACE_CFLAGS)
mipsel-unknown-elf-ld -q $($(ARCH)_LDFLAGS) $(ADD_LDFLAGS) -o $# $(filter %.o,$^) **-lm** -T $(filter %ldscript,$^) $(LIBGCC)*
However, entering the "make" command again, I got the following error:
mipsel-unknown-elf-ld: cannot find -lm
And now I don't know what to do.
Can anyone help me?
When you entered the "make" command, you got the following error:
mipsel-unknown-elf-ld: cannot find -lm
The "mipsel-unknown-elf-" says that you are using the mips cross compiler, and prefixes the "ld" linker-loader command. The -lm option says to link (the "-l" part) the "m" library, which is spelled "libm.a" or "libm.so". Which means that make compiled your
code, and now is trying to link your object file with the "libm" library.
See this link for some more information,
How does a C compiler find that -lm is pointing to the file libm.a?
What you want to do now is tell your linker-loader what path(s) to search for your libraries, which means you need to find "libm.a" and/or "libm.so", and the other libraries that you plan to use, "lib*.a" and "lib*.so*". Determine what paths you need, and then you add these library search paths by using the "-L path" option.
And now you know what to do.
-Chuck