I am trying to link a precompiled BLAS dll to a Fortran example, the linker refuses.
I read:
gfortran can't find library that IS there unfortunately what helped there didn't work for me.
Specifically:
gfortran -o "Test2" ./main.o -l"C:/Users/abc/workspace/Test2/blasdyndbgx64.dll"
c:/Program Files (x86)/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lC:/Users/abc/workspace/Test2/blasdyndbgx64.dll
collect2.exe: error: ld returned 1 exit status
make: *** [Test2] Error 1
The previous link I provided recommended to use the -l"entire/path/filename.ext", yet it still throws at me that error whatever I try. Obviously the file is there,
dir to the path+filename finds the dll.
I guess that since compilers are not my strong side I am still missing something trivial.
Related
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})
I am attempting to follow the tutorial here for developing a "Hello, World" LLVM pass - I am using the guidelines linked by that tutorial here for doing so out of the LLVM source directory. However, when I attempt to follow this tutorial, CMake reports a number of errors internal to LLVM itself.
I have the following directory structure:
HelloWorld/
CMakeLists.txt
HelloWorld/
CMakeLists.txt
HelloWorld.cpp
My HelloWorld.cpp, and the two CMakeLists.txt are copy and pasted directly from the tutorials linked to above.
I run CMake HelloWorld and it successfully generates a CMake configuration. However, when I run make. I get numerous errors reported from within the LLVM codebase itself.
[ 50%] Building CXX object CMakeFiles/LLVMPassName.dir/Vectorize.cpp.o
In file included from /Volumes/andromeda/HelloWorld/HelloWorld.cpp:1:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/Pass.h:377:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/PassSupport.h:27:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/PassRegistry.h:20:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm-c/Core.h:18:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm-c/Support.h:17:
/usr/local/Cellar/llvm/3.6.2/include/llvm/Support/DataTypes.h:57:3: error: "Must #define
__STDC_LIMIT_MACROS before #including Support/DataTypes.h"
# error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"
^
/usr/local/Cellar/llvm/3.6.2/include/llvm/Support/DataTypes.h:61:3: error: "Must #define
__STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h"
# error "Must #define __STDC_CONSTANT_MACROS before " \
The list goes on and on and all of them refer to errors in LLVM header files. This is a clean install of LLVM using Homebrew. To get linking to work, I had to set CPLUS_INCLUDE_PATH to the Homebrew include directory for LLVM.
My first thought was that CMake was attempting to use a different compiler (Clang vs. GCC or vice versa), but setting CMAKE_CXX_COMPILER to point to either my clang or g++ installation did not help.
Does anyone have any ideas for what might be the problem here?
After following the link provided by #oak in the comments, I was able to get rid of the first two Support/DataType errors. However, many of the errors still remain.
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/Pass.h:377:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/PassSupport.h:27:
In file included from /usr/local/Cellar/llvm/3.6.2/include/llvm/PassRegistry.h:21:
/usr/local/Cellar/llvm/3.6.2/include/llvm/ADT/DenseMap.h:543:63: error: a space is required
between consecutive right angle brackets (use '> >')
typename BucketT = detail::DenseMapPair<KeyT, ValueT>>
^
/usr/local/Cellar/llvm/3.6.2/include/llvm/ADT/DenseMap.h:694:63: error: a space is required
between consecutive right angle brackets (use '> >')
typename BucketT = detail::DenseMapPair<KeyT, ValueT>>
So, after much research, it turns out that there is an inconsistency with how LLVM and CMake support out-of-source builds. The LLVM binaries are built with -fno-rtti, so CMake will complain about missing symbols unless it is also uses -fno-rtti when compiling the LLVM pass.
I fixed all of my troubles (including those solved by the temporary fix proposed by Oak) by adding SET(CMAKE_CXX_FLAGS "-Wall -fno-rtti") to my CMakeLists.txt file in the innermost directory.
This was inspired by this question also on StackOverflow.
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 got this error when trying to compile a cpp code
c:\mingw\bin>g++ hello.cpp
g++: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found
compilation terminated
what is going wrong?
you have (or the build-system has) specified the flag -fuse-linker-plugin which requires the dynamic library file liblto_plugin-0.dll to be in your library search path, but the linker cannot find it.
btw, you could have discovered that by carefully reading the error message you got.
When I try to build this project with cmake and gcc on a 64-bit linux (debian) machine, I get an error from the linker:
Linking C executable ../../../../cpsadamsx
/home/dala/lib64/libSimTKcommon.so: undefined reference to `dlopen'
/home/dala/lib64/libSimTKcommon.so: undefined reference to `dlclose'
/home/dala/lib64/libSimTKcommon.so: undefined reference to `dlerror'
/home/dala/lib64/libSimTKcommon.so: undefined reference to `dlsym'
collect2: ld returned 1 exit status
make[2]: *** [cpsadamsx] Error 1
make[1]: *** [sundials/examples/cpodes/serial/CMakeFiles/cpsadamsx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Apparently dlopen, dlclose, dlerror and dlsym are references to libdl.so. I have that library in /lib64/libdl.so.2, but why is it not found?
Would it have been a normal './configure; make; make install'-path I could have set the LIBS variable and issued the configure command like this (I think):
export LIBS=-ldl && ./configure
But how do I do it now?
UPDATE:
So it seems that the (or at least a) library is found, but does not contain the symbols in question. Perhaps it tries with the 32-bit library in /lib?
Is there a way to disassemble /lib64/libdl.so.2 to make sure it does have the references dlopen etc?
The problem now seems to guide the build tools to the correct version of the library.
As this question is showing up on google and both answers won't point to the correct solution here it is:
In your CMakeLists.txt add ${CMAKE_DL_LIBS} to link against idl.
It should look similar to this:
target_link_libraries(ExpandableTest
${CMAKE_DL_LIBS}
Expandable
ExpandableTestLibrary
)
Probably you need to add target_link_libraries() - see link text
Add this in CMakeLists.txt and it should work:
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ldl")