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
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");
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
Im trying to compile bumblebee sat-solver from http://amit.metodi.me/research/bee/. I have installed SWI-Prolog and MinGW already but after i type "make-minisat" in cmd i get:
A subdirectory or file ..\satsolver already exists.
In file included from Solver.h:27:0,
from pl-minisat.cpp:6:
../utils/Options.h:285:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "%4"PRIi64, range.begin);
^
../utils/Options.h:291:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "%4"PRIi64, range.end);
^
../utils/Options.h:293:25: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "] (default: %"PRIi64")\n", value);
^
In file included from ../core/Solver.h:27:0,
from Solver.cc:24:
../utils/Options.h:285:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "%4"PRIi64, range.begin);
^
../utils/Options.h:291:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "%4"PRIi64, range.end);
^
../utils/Options.h:293:25: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
fprintf(stderr, "] (default: %"PRIi64")\n", value);
^
pl-minisat.obj:pl-minisat.cpp:(.text+0x13): undefined reference to `PL_get_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x4d): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x76): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x18a): undefined reference to `PL_unify_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x1b4): undefined reference to `PL_get_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x1ed): undefined reference to `PL_unify_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x220): undefined reference to `PL_copy_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x227): undefined reference to `PL_new_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x23c): undefined reference to `PL_unify_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x24f): undefined reference to `PL_get_list'
pl-minisat.obj:pl-minisat.cpp:(.text+0x271): undefined reference to `PL_unify_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x298): undefined reference to `PL_new_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x29f): undefined reference to `PL_new_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x2a9): undefined reference to `PL_put_nil'
pl-minisat.obj:pl-minisat.cpp:(.text+0x2ec): undefined reference to `PL_put_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x2ff): undefined reference to `PL_cons_list'
pl-minisat.obj:pl-minisat.cpp:(.text+0x314): undefined reference to `PL_unify'
pl-minisat.obj:pl-minisat.cpp:(.text+0x33e): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x38d): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x3cb): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x3d7): undefined reference to `PL_register_extensions'
pl-minisat.obj:pl-minisat.cpp:(.text+0x3e3): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text+0x44a): undefined reference to `PL_new_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x457): undefined reference to `PL_copy_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x47e): undefined reference to `PL_get_list'
pl-minisat.obj:pl-minisat.cpp:(.text+0x497): undefined reference to `PL_get_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x51a): undefined reference to `PL_get_nil'
pl-minisat.obj:pl-minisat.cpp:(.text+0x5fa): undefined reference to `PL_new_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x607): undefined reference to `PL_copy_term_ref'
pl-minisat.obj:pl-minisat.cpp:(.text+0x62e): undefined reference to `PL_get_list'
pl-minisat.obj:pl-minisat.cpp:(.text+0x647): undefined reference to `PL_get_integer'
pl-minisat.obj:pl-minisat.cpp:(.text+0x6ca): undefined reference to `PL_get_nil'
pl-minisat.obj:pl-minisat.cpp:(.text+0x808): undefined reference to `Sdprintf'
pl-minisat.obj:pl-minisat.cpp:(.text.startup+0x21): undefined reference to `PL_initialise'
pl-minisat.obj:pl-minisat.cpp:(.text.startup+0x31): undefined reference to `PL_halt'
pl-minisat.obj:pl-minisat.cpp:(.text.startup+0x36): undefined reference to `PL_toplevel'
pl-minisat.obj:pl-minisat.cpp:(.text.startup+0x46): undefined reference to `PL_halt'
collect2.exe: error: ld returned 1 exit status
g++ returned code 1
*** swipl-ld exit status 1
It looks like g++ can't reach prolog header files. Any ideas? I work on win 10, 64 bits.
There is a beta feature of Windows 10 know as WSL (Windows Subsystem for Linux), or Bash on Windows, or Bash on Ubuntu on Windows.
Bash on Windows provides developers with a familiar Bash shell and
Linux environment in which you can run most Linux command-line tools,
directly on Windows, UNMODIFIED, without needing an entire Linux
virtual machine!
I have used it to install SWI-Prolog and run some of my own Prolog programs. AFAIK I might be the only one on the planet to have done this.
I have installed it using the
PPA
or
sudo apt-get install swi-prolog-nox -y.
The PPA installs a newer version.
Plan on spending about an hour from the time you start to the time you get everything installed and updated as you are literally downloading and installing Ubuntu and all the apps from the ground up.
The WSL installation guide is here.
You are probably not on the Windows insider program, so DO NOT follow For Windows Insiders: Install Linux distribution of choice but instead follow For Anniversary Update and Creators Update: Install using lxrun.
If you run into problems I can help you, or you can post issues on the GitHub issues page, or use the SO tag wsl, or use the Ask Ubuntu tag wsl, or use the SuperUser tag windows-subsystem-linux.
I initially used it for this problem.
You need to read all of the pages noted on the left of the home page.
Breadcrumbs
Using Windows 10 install WSL per installation guide
Use the right instruction set:
For Anniversary Update and Creators Update: Install using lxrun
Note: The rest of the instructions are done within WSL or an app run from WSL
Install gcc
sudo apt-get -y install build-essential
Install SWI-Prolog - used PPA
Create directory for Bee
mkdir Bee
On my system it is eric#WINDOWS:~/projects/Bee$
Change to the Bee directory
cd ~/projects/Bee
Download Bee
wget http://amit.metodi.me/research/bee/bee20170615.zip
Uncompress zip
I installed and used 7-Zip
sudo apt-get install p7zip-full
7z x bee20170615.zip
Change to the source code directory
cd satsolver_src
Read README.txt
Build solvers using make
make satSolvers
eric#WINDOWS:~/projects/Bee/satsolver_src$ make satSolvers
rm -r -f ../satsolver
mkdir -p ../satsolver
tar xf ../satsolver_src/plSATsolver.tar.gz -C ../satsolver
tar -xf plMiniSAT_src.tar.gz -C ../satsolver
(cd ../satsolver/prologinterface && ./configure && make)
make[1]: Entering directory '/home/eric/projects/Bee/satsolver/prologinterface'
rm -f *.so
g++ -Wno-unused-result -D __STDC_LIMIT_MACROS -D __STDC_FORMAT_MACROS -O3 -fomit-frame-pointer -s -shared -fpic -o pl-minisat.so pl-minisat.cpp \
../minisat-2.0.2/core/Solver.cc \
-L/usr/lib/swi-prolog/lib/amd64 \
-I /usr/lib/swi-prolog/include \
-I ../minisat-2.0.2/ \
-I ../minisat-2.0.2/core
make[1]: Leaving directory '/home/eric/projects/Bee/satsolver/prologinterface'
mv ../satsolver/prologinterface/pl-minisat.so ../satsolver/pl-minisat.so
rm -r -f ../satsolver/minisat-2.0.2
rm -r -f ../satsolver/prologinterface
tar xf ../satsolver_src/plGlucose_src.tar.gz -C ../satsolver
(cd ../satsolver/prologinterface && ./configure && make)
make[1]: Entering directory '/home/eric/projects/Bee/satsolver/prologinterface'
rm -f *.so
g++ -Wno-unused-result -D __STDC_LIMIT_MACROS -D __STDC_FORMAT_MACROS -O3 -fomit-frame-pointer -s -shared -fpic -o pl-glucose.so pl-glucose.cpp \
../glucose-2.2/core/Solver.cc \
-L/usr/lib/swi-prolog/lib/amd64 \
-I /usr/lib/swi-prolog/include \
-I ../glucose-2.2/ \
-I ../glucose-2.2/core
make[1]: Leaving directory '/home/eric/projects/Bee/satsolver/prologinterface'
mv ../satsolver/prologinterface/pl-glucose.so ../satsolver/pl-glucose.so
rm -r -f ../satsolver/glucose-2.2
rm -r -f ../satsolver/prologinterface
tar xf ../satsolver_src/plGlucose4_src.tar.gz -C ../satsolver
(cd ../satsolver/prologinterface && ./configure && make)
make[1]: Entering directory '/home/eric/projects/Bee/satsolver/prologinterface'
rm -f *.so
g++ -Wno-unused-result -D __STDC_LIMIT_MACROS -D __STDC_FORMAT_MACROS -O3 -fomit-frame-pointer -s -shared -fpic -o pl-glucose4.so pl-glucose4.cpp \
../glucose-4/core/Solver.cc \
-L/usr/lib/swi-prolog/lib/amd64 \
-I /usr/lib/swi-prolog/include \
-I ../glucose-4/ \
-I ../glucose-4/core
make[1]: Leaving directory '/home/eric/projects/Bee/satsolver/prologinterface'
mv ../satsolver/prologinterface/pl-glucose4.so ../satsolver/pl-glucose4.so
rm -r -f ../satsolver/glucose-4
rm -r -f ../satsolver/prologinterface
eric#WINDOWS:~/projects/Bee/satsolver_src$
Verify executables created
cd ..
cd satsolver
ll
eric#WINDOWS:~/projects/Bee/satsolver$ ll
total 372
drwxrwxrwx 0 eric eric 4096 Jul 31 07:12 ./
drwxrwxrwx 0 eric eric 4096 Jul 31 07:11 ../
-rwxrwxrwx 1 eric eric 101200 Jul 31 07:12 pl-glucose4.so*
-rwxrwxrwx 1 eric eric 80656 Jul 31 07:12 pl-glucose.so*
-rwxrwxrwx 1 eric eric 68360 Jul 31 07:12 pl-minisat.so*
-rw-r--r-- 1 eric eric 10268 Apr 1 2016 satsolver.pl
eric#WINDOWS:~/projects/Bee/satsolver$
Run first example from README.txt
swipl
[satsolver].
sat([[A,-B],[-A,B]]).
eric#WINDOWS:~/projects/Bee/satsolver$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 7.4.2)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit http://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
?- [satsolver].
% SWI-Prolog interface to Glucose v2.2 ... OK
true.
?- sat([[A,-B],[-A,B]]).
A = B, B = -1.
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/
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 ?