See the thing is, there is no such thing as a file to link to named glscblas because that's a typo.
Here's an example of the problem when Rstudio calls gcc:
install.packages('devtools')
gcc -std=gnu99 -shared -L/usr/lib/R/lib -L/usr/lib/x86_64-linux-gnu -lgsl -lglscblas -o openssl.so aes.o base64.o bignum.o cert.o compatibility.o diffie.o envelope.o error.o hash.o info.o keygen.o keys.o onload.o openssh.o password.o pem.o pkcs12.o pkcs7.o rand.o rsa.o signing.o ssl.o stream.o write.o -L/usr/lib/x86_64-linux-gnu -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find -lglscblas
Where could the filename typo be hiding, that is, what file holds the filename that feeds -l parameters to gcc when calling install.packages in Rstudio? Rstudio invokes gcc with some wrong linker parameter that's obviously a typo for gnu scientific library "gslcblas" -- notice the gls / gsl character ordering mixup. It's harming the build anytime I run the command install.packages when it depends on the gnu scientific library, which is a lot of packages. It's crippling my Rstudio system. Installing today's latest Rstudio did not fix it. I can't seem to find the file that has the typo. Can anyone help me find the file containing the typo? thank you so much for helping. The RStudio forums were unresponsive, so I'm here now.
Rstudio server, Ubuntu 16.04, gcc. Additionally:
ga#ga-HP-Z820:~/Downloads$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
ga#ga-HP-Z820:~/Downloads$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
libraries:
/usr/lib/nvidia-current/x86_64-linux-gnu/5/:/usr/lib/nvidia-current/x86_64-linux-gnu/:/usr/lib/lib/:./x86_64-linux-gnu/5/:./x86_64-linux-gnu/lib/:/usr/lib/nvidia-current/x86_64-linux-gnu/5/:/usr/lib/nvidia-current/x86_64-linux-gnu/:/usr/lib/lib/:./x86_64-linux-gnu/5/:./x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/:/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/x86_64-linux-gnu/lib/:/usr/lib/x86_64-linux-gnu/5/:/usr/lib/x86_64-linux-gnu/:/usr/lib/:/lib/x86_64-linux-gnu/5/:/lib/x86_64-linux-gnu/:/lib/:/usr/lib/x86_64-linux-gnu/5/:/usr/lib/x86_64-linux-gnu/:/usr/lib/:/usr/lib/nvidia-current/:./:/usr/lib/nvidia-current/:./:/usr/x86_64-linux-gnu/lib/:/usr/lib/:/lib/:/usr/lib/
Related
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
I am trying to cross compile openssl using the x86_64-linux-gnu-gcc on a Fedora 29 host.
I am getting this error:
cryptlib.h:62:11: fatal error: stdlib.h: No such file or directory
The compile command is:
x86_64-linux-gnu-gcc -o cryptlib.o cryptlib.c
As I understand it, the compiler should find stdlib.h in it's standard path since it has been included with <..>.
I tried testing for it using the pre processor, which said that it can't find it.
echo '#include <stdlib.h>' | x86_64-linux-gnu-cpp -H -o /dev/null
:1:10: fatal error: stdlib.h: No such file or directory
I tested for another header file, it it was able to find it.
echo '#include <stdbool.h>' | x86_64-linux-gnu-cpp -H -o /dev/null
. /usr/lib/gcc/x86_64-linux-gnu/8/include/stdbool.h
Has anyone come across this issue ?.
Regards
Chandana
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.