I am understanding how vmlinux will create with the help of link-vmlinux.sh script, I could see it is passing -p option to the linker while building vmlinux, but I couldn't see any option named -p when executed linker with --help.
#arm-linux-gnueabihf-ld -EL -p --no-undefined -X --build-id -o vmlinux
Can you please tel me what is the use of '-p' option in the above command.
I reckon it prints the program headers object file format uses also known as
segments.The program headers describe how the program should be loaded into memory. You can print them out by using the objdump program with the -p option.
Did you try arm-linux-gnueabihf-ld --help ?
Related
I have a manual process for compiling a Linux kernel for an embedded ARM device. I use the CONFIG_APPENDED_DTB=y option, append my DTB file to the zImage file, then convert to uImage:
cat arch/arm/boot/zImage ./arch/arm/boot/dts/lpc3250-phy3250.dtb > arch/arm/boot/zImage-dtb
mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' \
-d arch/arm/boot/zImage-dtb arch/arm/boot/uImage
I'm attempting to migrate to Yocto. How can I implement the same process? I can set KERNEL_IMAGETYPE = "zImage" but I'm not sure how to postprocess the zImage file.
Note that my version of u-boot is fixed and quite old, so I am not currently considering migrating to other formats such as FIT.
I am a newcomer to Yocto, so expository answers are especially welcome.
I'm trying to link against ffmpeg libraries, in rust, and getting as the only error:
undefined reference to `vdp_device_create_x11'
Here's the libs linked:
fn main() {
println!("cargo:rerun-if-changed=build.rs");
println!("cargo:rustc-link-lib=static=z");
println!("cargo:rustc-link-lib=dylib=dl");
println!("cargo:rustc-link-lib=static=X11");
println!("cargo:rustc-link-lib=dylib=vdpau");
println!("cargo:rustc-link-lib=dylib=va");
println!("cargo:rustc-link-lib=dylib=va-drm");
println!("cargo:rustc-link-lib=dylib=va-x11");
println!("cargo:rustc-link-lib=dylib=xcb");
}
On C++ I used to link with all these libs above + some for GTK and it worked. Don't know why it wont work now.
On errors when compiling c code with ffmpeg library it says that I should link against -lvdpau - libvdpau-dev
I tried adding
println!("cargo:rustc-link-lib=dylib=vdpau-dev");
but I get
= note: /usr/bin/ld: cannot find -lvdpau-dev
Even though I installed libvdpau-dev. Indeed,
ldconfig -p | grep vdpau
libvdpau.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libvdpau.so.1
libvdpau.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libvdpau.so
Why libdpau-dev is missing? I'm on ubuntu 20, apt-get install -y libdpau-dev. Finny thing is that C++ compiles perfectly in this same docker container without any modifications and without libdpau-dev
UPDATE:
nm -D /lib/x86_64-linux-gnu/libvdpau.so | grep x11
0000000000001d50 T vdp_device_create_x11
UPDATE:
note: /usr/bin/ld: /home/dev/orwell/liborwell_rust/target/debug/deps/libffmpeg_sys_next-109176c9182219d2.rlib(hwcontext_vdpau.o): in function `vdpau_device_create':
hwcontext_vdpau.c:(.text+0x686): undefined reference to `vdp_device_create_x11'
The file hwcontext_vdpau.o is from ffmpeg: https://ffmpeg.org/doxygen/trunk/hwcontext__vdpau_8c_source.html
My theory of why it worked for your case but not mine is that in your case you link these libraries after the code that uses vdp_device_create_x11. In my case, I think it links my code against the libs I provided + ffmpeg libs. So maybe ffmpeg libs come after or before the libs I provided.
Well, since I'm linking against the project that links with ffmpeg, I think this is what's happening:
my_code is being linked against ffmpeg-sys-next crate + libs I provided. Where ffmpeg-sys-next crate contains the ffmpeg libs. I just don't know if the order is
ffmpeg-sys-next crate + libs I provided
or
libs I provided + ffmpeg-sys-next crate.
If ffmpeg needs vdp_device_create_x11, then vdp_device_create_x11 should come before ffmpeg or after?
Is it possible to control if the crate dependencies are linked after or before the libs I provided?
UPDATE:
Running `rustc --crate-name liborwell_rust --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=a40686dab33e6453 -C extra-filename=-a40686dab33e6453 --out-dir /home/dev/orwell/liborwell_rust/target/debug/deps -C incremental=/home/dev/orwell/liborwell_rust/target/debug/incremental -L dependency=/home/dev/orwell/liborwell_rust/target/debug/deps --extern ffmpeg_next=/home/dev/orwell/liborwell_rust/target/debug/deps/libffmpeg_next-c150275f8ec2ece5.rlib --extern liborwellprofile_protobuf_rust=/home/dev/orwell/liborwell_rust/target/debug/deps/libliborwellprofile_protobuf_rust-85a803bf8441d976.rlib --extern phf=/home/dev/orwell/liborwell_rust/target/debug/deps/libphf-0282e4d662343769.rlib --extern protobuf=/home/dev/orwell/liborwell_rust/target/debug/deps/libprotobuf-525fd12c456cb486.rlib -l static=z -l dylib=dl -l dylib=vdpau -l static=X11 -l dylib=va -l dylib=va-drm -l dylib=va-x11 -l dylib=xcb -L native=/home/dev/orwell/deps/ffmpeg/build/linux/x86_64/lib`
Looks like the ffmpeg libraries are the last thing passed to the compiler/linker: -L native=/home/dev/orwell/deps/ffmpeg/build/linux/x86_64/lib
libvdpau-dev is the name of the development package, but libvdpau being the name of the library and the shared object file (libvdpau.so) you should pass -lvdpau to the linker.
That answer you linked to says to add that flag and then gives a link to the dev package.
println!("cargo:rustc-link-lib=dylib=vdpau");
Working through Jon Erickson's book on Hacking. He uses an intel format assembly code. He provides the following snippet:
reader#hacking:~/booksrc 08048374 <main>:
$ objdump -M intel -D
a.out | grep -A20 main.
I'm getting this error:
Mac-of-Thor:test thorkamphefner$ objdump -M
objdump: Unknown command line argument '-M'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump -help'
objdump: Did you mean '-C'?
What do I need to do to update objdump?
objdump on a Mac is llvm-objdump, not GNU Binutils objdump that takes command-line options like -Mintel
I think I've read that the standard ways of installing GNU binutils on Mac will give you gobjdump.
See Disassemble into x86_64 on OSX10.6 (But with _Intel_ Syntax)
objdump -disassemble -x86-asm-syntax=intel should work on a Mac (for llvm-objdump).
I am trying to statically link two COBOL files together using GnuCobol (Windows 10) following the example listed here: https://open-cobol.sourceforge.io/historical/open-cobol/Static-Linking.html but cannot seem to get it to work.
I am running the following:
cobc -free -c InterpFunc.cob
cobc -free -c -fmain Integrator.cob
cobc -x -o .\\dist\\integrator Integrator.o InterpFunc.o
The '.o' files compile correctly, but the binary never builds with the following errors:
H:\Programs\COBAL\cobc\bin\cobc.exe: unrecognized option '-fmain'
h:/programs/cobal/cobc/bin/../lib/gcc/mingw32/6.3.0/../../../libmingw32.a(main.o):(.text.startup+0xa0): undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
The terminal process terminated with exit code: 1
I have tried a few different things such as leaving out the '-fmain' or leaving out the '-x', but all seem to produce different errors.
Is this perhaps an issue with my compiler/system setup or am I misunderstanding how to statically link files?
I'm quite sure you do not use a compiler matching that old documentation (having "historical" in its URL). I'm quite sure it'll work the way the current manual says:
The easiest way of combining multiple files is to compile them into a single executable.
One way is to compile all the files in one command:
$ cobc -x -o prog main.cob subr1.cob subr2.cob
Another way is to compile each file with the option -c, and link them at the end. > The top-level program must be compiled with the option -x.
$ cobc -c subr1.cob
$ cobc -c subr2.cob
$ cobc -c -x main.cob
$ cobc -x -o prog main.o subr1.o subr2.o
So I have a file example.cpp which I have to compile with g++.
$ g++ nginx.cpp libuaparser_cpp.a -I ~/Desktop/boost_1_68_0/ -I /usr/local/mysql-connector-c++-8.0.12/include/jdbc/ -L /usr/local/mysql-connector-c++-8.0.12/lib64/ -L ~/Desktop/boost_1_68_0/stage/lib -L /usr/local/lib/ -L /Users/Shray/Desktop/boost_1_68_0/stage/lib/ ~/Desktop/boost_1_68_0/stage/lib/libboost_regex.a -lyaml-cpp -lboost_regex -std=c++11 -lmysqlcppconn
So instead of writing so much, I put the rest of the parameters in a variable in my terminal.
$ myvar="libuaparser_cpp.a -I ~/Desktop/boost_1_68_0/ -I /usr/local/mysql-connector-c++-8.0.12/include/jdbc/ -L /usr/local/mysql-connector-c++-8.0.12/lib64/ -L ~/Desktop/boost_1_68_0/stage/lib -L /usr/local/lib/ -L /Users/Shray/Desktop/boost_1_68_0/stage/lib/ ~/Desktop/boost_1_68_0/stage/lib/libboost_regex.a -lyaml-cpp -lboost_regex -std=c++11 -lmysqlcppconn"
$ g++ nginx.cpp $myvar
But this gives me an error.
clang: error: no such file or directory: '~/Desktop/boost_1_68_0/stage/lib/libboost_regex.a'
Why is this error coming? Since I am just adding the variables value. Any help would be much appreciated.
Don't use variables to store a content that is a list, use arrays! Also ~ doesn't expand under quotes (single or double)
myVarArgs=()
myVarArgs=( libuaparser_cpp.a
-I ~/Desktop/boost_1_68_0/
-I /usr/local/mysql-connector-c++-8.0.12/include/jdbc/
-L /usr/local/mysql-connector-c++-8.0.12/lib64/
-L ~/Desktop/boost_1_68_0/stage/lib
-L /usr/local/lib/
-L /Users/Shray/Desktop/boost_1_68_0/stage/lib/
~/Desktop/boost_1_68_0/stage/lib/libboost_regex.a
-lyaml-cpp
-lboost_regex
-std=c++11
-lmysqlcppconn
)
and run a full-quoted expansion to preserve the args from breaking up on presence of special characters.
g++ nginx.cpp "${myVarArgs[#]}"
Tilde expansion happens before variable expansion, so ~ in a variable isn't expanded to your home directory by the shell. Use the full path.