This question follows on from Can you tell me what "crus" means in "LDFLAGS = crus $#"?
Since my error message is "aarch64-poky-linux-ld: cannot find crus: No such file or directory",
where can I find documentation on aarch64-poky-linux-ld?
Best regards,
Next questions: How do I link in needed libraries to a new layer in Yocto?
How do I link librt and libpthread to a new layer in Yocto?
All Linux systems I know of use GNU ld as their linker, part of the binutils package, and it has a complete manual. The aarch64-poky-linux- prefix is a target triplet, used to identify which cross-compilation target this particular ld executable is for.
However, all I think it will tell you is that a string which is not part of an option (starting with - or --) will be treated as an input file. So the message just reports that it is trying to use crus as an input file but it doesn't exist. That's not surprising because as was pointed out on your other question, crus appears to be meant as options to the ar program, not for ld at all. They don't make sense in an LDFLAGS variable. So you will need instead to debug whatever makefile or script decided to try to pass those "options" to aarch64-poky-linux-ld in the first place.
Related
I'm trying to compile my first program which uses the NAG library, the following:
program naginfo
use nag_f77_a_chapter
implicit none
write(*,*) 'Calling NAG identification routine'
write(*,*)
call a00aaf
end program naginfo
This is copied from the tutorial and they suggest to compile it with the following statement:
f95 -o naginfo naginfo.f90 -lnag
and they suppose that this -lnag drives the linker to NAG library, but then I find this error:
Fatal Error: Can't open module file ‘nag_f77_a_chapter.mod’ for reading at (1): The directory does not exist
I've tried changing the directory of the NAG files to help the linker find it.
How do I get this to compile and link?
This is just a long explanation of francescalus's comment.
The flag -lnag only adds the library code to the already compiled program when linking all compiled pieces together. It has no effect during compilation and hence no effect on the error message you see.
The compiler must see the information about the NAG library modules. That is usually stored in module files with the .mod extension. Compilers normally only search for these in the current directory or in the system's include directories.
You can instruct the compiler to search in a different directory by using a special compiler flag. It may differ between different compilers, but is typically -I followed by the directory where the library stores its .mod files.
Be advised that the .mod files in the library are only compatible with the same compiler that was used to create them by the library vendor.
Say I have a binary server, and when it's compiled, it's linked from server.c, static_lib.a, and dynamically with dynamic_lib.so.
When server is executed and it loads dynamic_lib.so dynamically, but on the code path, dynamic_lib.so actually expects some symbols from static_lib.a. What I'm seeing is that, dynamic_lib.so pulls in static_lib.so so essentially I have two static_lib in memory.
Let's assume there's no way we can change dynamic_lib.so, because it's a 3rd-party library.
My question is, is it possible to make dynamic_lib.so or ld itself search the current binary first, or even not search for it in ld's path, just use the binary's symbol, or abort.
I tried to find some related docs about it, but it's not easy for noobs about linkers like me :-)
You can not change library to not load static_lib.so but you can trick it to use static_lib.a instead.
By default ld does not export any symbols from executables but you can change this via -rdynamic. This option is quite crude as it exports all static symbols so for finer-grained control you can use -Wl,--dynamic-list (see example use in Clang sources).
How do I add linker-flags "DEF" and "NODEFAULTLIB" to vs2012 project via CMAKE?
You can append them to CMAKE_EXE_LINKER_FLAGS:
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def /NODEFAULTLIB")
endif()
The general way is to add linker flags to CMAKE_xxx_LINKER_FLAGS, yes. However in case of CMAKE_SHARED_LINKER_FLAGS and /DEF: parameter, there is a special case that made me run into trouble.
If you already use CMAKE_EXPORT_ALL_SYMBOLS (CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS) then the /DEF: parameter will not appear in the linking command, even if you specified it in CMAKE_SHARED_LINKER_FLAGS.
This is because MSVC linker accepts only one /DEF: parameter, and CMake does not want to override the existing one: /DEF:<build_path>/exports.def (which is added due to CMAKE_EXPORT_ALL_SYMBOLS) with the one which you specify in the CMAKE_SHARED_LINKER_FLAGS.
You can use also CMAKE_CXX_STANDARD_LIBRARIES. It adds arbitrary linker flags without checking them, but it adds them into the middle of the linking command before the /DEF:<build_path>/exports.def so that the latter won't get overridden.
The full discussion of this case here: https://cmake.org/pipermail/cmake-developers/2019-November/031274.html.
Short:
I'm looking for something that will list all unresolved dependencies in an SO, taking into account the SOs that are in it's dependencies.
Long:
I'm converting a lot of static-compiled code to Shared Objects in Linux- is there an easy way to determine what other SOs my recently compiled SO is dependent on besides trial & error while trying to load it?
I'm sure there is a better way, but I haven't been able to find it yet.
I've found "ldd", but that only lists what the SO says it's dependent on.
I've also used "nm" to figure out once an SO fails to load to verify what other SO contains it.
I don't have code for you, but I can give pointers:
It's just a graph problem. You should use objdump -T to dump the dynamic symbol table for a given binary or shared object. You'll see many lines of output, and the flags can be a little confusing, but the important part if that symbols will either be *UND* or they'll have a segment name (.text etc).
Any time you see *UND*, that means that it's an undefined symbol which has to be resolved. Defined symbols are the targets of resolution.
With that, and a little Python, you should be able to find what you need.
"ldd -r foo.so" should print the set of symbols which foo.so needs but which aren't provided by its direct dependencies.
Alternatively, link foo.so like this:
gcc -shared -o foo.so foo.o bar.o -ldep1 -ldep2 -Wl,--no-undefined
This should fail (to link) if foo.o or bar.o uses something not provided by libdep1 or libdep2 or libc.
What does the obj file ctr1.o does in gcc compilier ?Why does the linker link this obj file whenever an executable is generated?
I think it contains very basic stuf (crt stands for C run time) like setting up argv and argc for your main function etc ... Here is a link with some explanation
If you don't want it, because you are writing a tiny bootloader for example, without any bit of the libc, you can use the --no-stdlib options to link your program. If you go this way, youwill also need to write your own linker script.
I'm not sure to understand your question but I guess you are referring to 'crt1.o' in the GCC package.
The crt is one of the base packages of the libc which provides basic functionality to access the computer. IIRC it contains methods like 'printf' and such.
That's why it is often even included in the most basic C applications.
Object files hold your compiled code, but are not in themselves executable. It is the job of the linker to take all the object files that make up a program, and join them into a whole. This involves resolving references between object files (extern symbols), checking that there is a main() entrypoint (for C programs), and so on.
Since each source file (.c or .cpp) compiles into a separate object file, which are then read by the linker, changes to a single C file mean only that can be re-compiled, generating a new object file, which is then linked with the existing object files into a new executable. This makes development faster.
UPDATE: As stated in another answer, the "crt.o" object files holds the C runtime code, which is assumed to be needed by most C programs. You can read the gcc linker options and find the --no-stdlib option, this will tell gcc that your particular program should not be linked with the standard C runtime files.