I compiled the MongoDB C Drivers successfully and run the test scripts also but I am not able to compile the scripts which I am writing myself.
Following is the command and its error output.
$ gcc -Isrc --std=c99 ./src/*.c -I ./src/ tutorial.c -o tutorial -D_POSIX_C_SOURCE=200112L
./src/env_win32.c:27:53: fatal error: ws2tcpip.h: No such file or directory
compilation terminated.
I found that there is no file name ws2tcpip.h in /usr/include directory
Take out the ./src/*.c, that tells gcc to compile all of the c programs in the /src directory which includes some windows only programs.
What worked for me was to tell gcc to include the libmongoc.so that was built when the drivers were built.
The following command worked for me. My drivers are in directory "mongo-c-driver".
gcc --std=c99 -I mongo-c-driver/src -o tutorial tutorial.c mongo-c-driver/libmongoc.so
In my opinion the mongodb C API documentation is a little buggy in this area. Also, the latest header files don't match the source code shown in the tutorial. For example mongo-insert requires 4 parameters in the v0.6 headers, but the tutorial shows only 2 parameters.
In researching this problem and trying to recreate it by installing mongoDB and the C driver myself I have discovered that v0.6 of the driver broke compatibility with previous version of the API by adding support for write_concern which adds a 4th parameter to the mongo_insert function (which can be set to null). The example.c program provided in the docs/examples directory does not compile in v0.6. This bug is documented in patch CDRIVER-157 in github for the c-driver.
Related
I have been attempting to link a MACHO formatted object file on Linux, but I have failed miserably. So far, I have created the object file by running:
nasm -fmacho -o machoh.o hello.o
I have tried linking using:
clang --target=x86_64-apple-darwin machoh.o
but that failed. I have attempted using GCC, LD, and other linkers but I have still failed miserably. Are there any ideas on how I could solve my problem?
Thank you very much.
The most accessible solution would be lld, the LLVM linker.
lld does not ship with clang, but is a separate package.
sudo apt install lld
If you installed a version of clang that isn't the default (e.g. clang-12 explicitly), then you should use the same version for lld (i.e. lld-12).
Get a MacOS SDK from somewhere. This GitHub repo archives them.
If you're uncomfortable using the above, the "legitimate" way of obtaining it without a Mac would be:
Create an Apple ID
Go to https://developer.apple.com/download/all/
Download the "Command Line Tools for Xcode <version>"
Mount or extract the dmg
Extract the XAR package
For each ".pkg" folder inside, run pbzx <Payload | cpio -i
Find the Library/Developer/CommandLineTools/SDKs/MacOSX.sdk inside.
Feed both of the above to clang:
clang --target=x86_64-apple-darwin -fuse-ld=lld --sysroot=path/to/MacOSX.sdk machoh.o
I have tried linking using: clang --target=x86_64-apple-darwin machoh.o
but that failed.
Failed how? Details matter.
Anyway, there are 3 commonly used linkers on Linux: BFD-ld, Gold, and (newest) LLD.
Of these, Gold is an ELF-only linker, and will not work for Mach-O.
BFD-ld is only configured to support a few emulations (use ld --help to see which ones) in my distribution. BFD does appear to support Mach-O, so it's probably possible to build a Linux BFD-ld cross-linker with such support.
LLD should support Mach-O out of the box, but you are probably not using LLD.
So your first step should be to figure out which linker clang --target=x86_64-apple-darwin ... uses, and then make it use the one which does support Mach-O.
I am using Windows subsystem for linux for Ubuntu and I am very new to this. I am trying to build the program (AutoDock Vina) from its source code provided on GitHub - GitHub Link.
In its installation procedure - provided here, it's mentioned that - To compile the binary (you might need to customize the Makefile by setting the paths to the Boost library)
Makefile has the following code written in it -
BASE=/usr/local
BOOST_VERSION=
BOOST_INCLUDE = $(BASE)/include
C_PLATFORM=-static -pthread
GPP=/usr/bin/g++
C_OPTIONS= -O3 -DNDEBUG -std=c++11
BOOST_LIB_VERSION=
include ../../makefile_common
I had previously installed Boost and SWIG using apt-get command as mentioned in the manual.
sudo apt-get install libboost-all-dev swig
When I tried to find out location of Boost library, I found that at following two places boost related files are there -
/usr/lib/x86_64-linux-gnu/ and
/lib/x86_64-linux-gnu/ (these two folders have many files having names starting with libboost)
/usr/include/boost/ (this appears to be main folder for boost)
But, I tried many combinations to the BASE value in Makefile, but in all cases, after building the files, I see the executable named Vina (as expected) is built in the folder but when I try to run the same on terminal, I get command not found error.
Please help me with this - how to find out Boost related values for Makefiles?
Edit 1 - After reading the comment from #MadScientist, I have realized it's not a problem of Boost library but the issue I am facing is because of PATH not set. So I will follow his comment and proceed.
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
i am new to stackflow and i previously i have no background in computer system and programming. However, now i need to run analysis under cygwin for my bioinformatics project. I encounter some error when i try to compile a file name 'zone_b.linux'using cygwin, to produce an executable program. The linux file is download from web https://github.com/haddocking/HADDOCK-binding-sites-tutorial/blob/master/ana_scripts/zone_b.linux. When i try to compile using the following command under cygwin it produce the following error:
$ gcc zone_b.linux
/usr/lib/gcc/i686-pc-cygwin/6.4.0/../../../libcygwin.a(libcmain.o): In
function `main':
/usr/src/debug/cygwin-2.9.0-3/winsup/cygwin/lib/libcmain.c:37: undefined
reference to `WinMain#16'
collect2: error: ld returned 1 exit status
Error description
I search the following error under stackoverflow, and i found two post with similar problem.
First is the post from undefined reference to `WinMain#16'. It stated that the problem is due the Microsoft'linker uses a runtime library entry point(winMainCRTStartup) that calls Microsoft's non-standard WinMain instead of standard main. So, i try the post's suggestion of including the entry by following command
$ gcc zone_b.linux /entry:winMainCRTStartup
gcc: error: /entry:winMainCRTStartup: No such file or directory
However i get the error no such file or directory. I think maybe it is because i am running under cygwin not mingW.
Second post is the Undefined reference to WinMain in Cygwin. From the post, it said use -c compile flag to only produce object file. However, for my case, i am not using any -c. Therefore, i think it is not relevant to my issue.
I would appreciate if anyone could kindly explain to me since i am new to this computing area. Thank you.
zone_b.linux is the compiled and linked executable program to run on a linux machine. It is a 32-bit ELF binary file. It will not work on a Windows machine, even using cygwin or mingw32, without re-compulation.
You probably have to compile zone_b.f, a FORTRAN source file, using the gfortran compiler to create a zone_b.exe that is usable in cygwin. I saw no instructions for this, but try something like gcc zone_b.f and cross fingers. Be sure gfortran is installed using cygwin setup.
You will also need to (re-)build the other executables (cluster_struc and contact) by performing make in the ana_scripts directory. Any supplied executables (from the git clone ... or a downloaded .zip file) will not work under cygwin.
You will need to have perl and python installed. I think perl is installed by default. You can install python2 using cygwin setup. The python script looked like it will work with python2 or python3, whichever is the default. On cygwin, today, python2 is the default python. I don't do perl, so cross your fingers.
I am installing Open MPI v1.8.8 with CUDA v7.5 on my Linux Debian.
I have tested CUDA and it works, tested OpenMPI and it works too. But when i try to combine them into a program, i meet an error: cannot find cuda.h file . This is my scenario:
My program source code include these .h file
include "cuda.h"
include "mpi.h"
I run command:
mpicc <filePath> -o test
And error appear:cuda.h: No such file or directory
#include "cuda.h"`
omp_info give me : mca:mpi:base:param:mpi_built_with_cuda_support:value:false
I have googled , and i followed some methods i found:
./configure --with-cuda
./configure --with-cuda=/usr/local/cuda-7.5
( source link : http://mirror.its.dal.ca/openmpi/faq/?category=buildcuda)
After that, i remake all , remake install Open Mpi. I run: mpicc or mpirun, the compiler give me error : mpirun error mca: base: component find: unable to open /usr/local/lib/openmpi/mca_mpool_sm
I set up soft link : ln -s /usr/local/cuda/include /usr/include ( describe in link : Building CUDA-aware openMPI on Ubuntu 12.04 cannot find cuda.h).
But it cannot fix my issue.
Does anyone successfully install it? Please help me or share your experience.
Thanks.
I think you are confusing installation problems with incorrect compiler options. It will be necessary to explicity specify the include paths, library paths, and libraries for CUDA when compiling and linking host code with your mpi wrapped host compiler.
Something like:
mpicc -I/usr/local/cuda-7.5/include -L/usr/local/cuda-7.5/lib -o test <filePath> -lcuda
would be the normal way to build a simple MPI program which call the cuda driver APIs. You will need to add nvcc compilation for device code and host code which uses the runtime API.
The apparent lack of CUDA support in your MPI flavour is a separate question and one you should probably take up in another forum (like the user mailing list of the MPI flavour you use).