Issues with setup of Coin-CLP - c++

I am trying to setup Coin-CLP that supports also CPLEX (which I have installed and is running smoothly on my machine) following the instructions found on the website.
Unfortunately when I try to run the configure step on the installation, that in my version where I want to include CPLEX as well looks like this:
./configure --with-cplex \
--with-cplex-lib="-L/opt/ibm/ILOG/CPLEX_Studio127/cplex/lib/x86-64_linux/static_pic -lilocplex -lconcert -lcplex -lm -lpthread" \
--with-cplex-incdir="/opt/ibm/ILOG/CPLEX_Studio127/cplex/include/ilcplex" \
--enable-static -C
I receive the following error:
checking whether symbol CPXgetstat is available with CPX... no
configure: error: Cannot find symbol(s) CPXgetstat with CPX
configure: error: /bin/bash './configure' failed for Osi
I have tried to search online and find similar issues and proposed solutions, but unfortunately so far I haven't managed to find any way to fix this.
So, any help would be really appreciated!

I've recently stumbled against this same issue trying to enable Fast-Downward planner to work with LP capabilities. I know this is an old question, but it is one of the few pages that show up when searching for this error, so I thought I may as well give my solution for it.
After digging through the config.log file inside the Osi folder, I found that there were undefined references to the functions from the DL (Dynamically Loaded) library, such as dlopen. So I added -ldl to the --with-cplex-lib configure argument. My configure call was like this at the end:
./configure CC="gcc" CFLAGS="-m64 -pthread -Wno-long-long" CXX="g++" \
CXXFLAGS="-m64 -pthread -Wno-long-long" LDFLAGS="-L$DOWNWARD_CPLEX_ROOT64/lib/x86-64_linux/static_pic/"\
--without-lapack --enable-static=yes --prefix="/usr/local/" --disable-zlib --disable-bzlib\
--with-cplex-incdir=$DOWNWARD_CPLEX_ROOT64/include/ilcplex --with-cplex-lib="-lcplex -lm -ldl"
Hope it helps.

Related

R install packages looking in wrong place

Trying to install FFTW and feel like I have been going in circles. I need it for an R package (poisbinom) and I think I have it installed right (I'm on a cluster and don't have sudo privileges. I followed the instructions here: http://micro.stanford.edu/wiki/Install_FFTW3 )
The problem I'm running into is this:
g++ -std=gnu++14 -shared -L/usr/local/lib64 -o poisbinom.so RcppExports.o init.o poisbinom.o -lfftw3 -lm
/usr/bin/ld: cannot find -lfftw3
collect2: error: ld returned 1 exit status
I have a feeling it is because I did not install FFTW under usr/local/lib64, its under $HOME/usr/. My R install is under $HOME/R/lib64/R. I am not sure what variable to change to make it look in the right place, as I cant change this g++ call as it is part of an R install.packages call. I've been going in circles with this for two days now. Let me know if theres anything else I can provide to help.
I already ran install.packages("fftw") and that was successful and used LFFTW3 without issue because it looked in the right place. I mostly just need to know if I can point this gcc call to the right folder with an environment variable or something.
In case you have pkg-config on your system and your installation produced the required configuration files (e.g. fftw3.pc): Define the environment variable PKG_CONFIG_PATH to (also) include the directory with these configuration files for FFTW3.
Otherwise, you can define FFTW_CFLAGS and FFTW_LIBS:
fftw$ ./configure --help
[...]
FFTW_CFLAGS C compiler flags for FFTW, overriding pkg-config
FFTW_LIBS linker flags for FFTW, overriding pkg-config
[...]
I ended up having to add the variables to my bashrc file:
export PATH=$HOME/fftw_folder/bin:$PATH
export LD_LIBRARY_PATH=$HOME/fftw_folder/lib:$LD_LIBRARY_PATH
export LIBRARY_PATH=$HOME/fftw_folder/lib:$LIBRARY_PATH
export PKG_CONFIG_PATH=$HOME/_folder/lib/pkgconfig:$PKG_CONFIG_PATH
As laid out here: http://hpc.loni.org/docs/faq/installation-details.php
And now things seem to be moving forward smoothly. Thanks for the help!

Sysgcc: ld.exe cannot find -lcurl -ljsoncpp

I'm working on a project on a Raspberry Pi 2 Model B. I started coding and compiling directly on the Pi and now I want to work on a Windows 7 PC. I already installed the SysGCC Cross-Compiler and managed to compile a simple Hello-World program.
Problem is, for my Project i use curl and jsoncpp. Natively on the Raspberry i have no problems compiling it, but the cross-compiler on Windows gives me following error:
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lcurl
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -ljsoncpp
I don't use a makefile or so because i never really worked with that and on the raspi it just worked fine with this command:
g++ ../src/rpi/main.cpp ../src/rpi/connection.cpp ../src/rpi/jsonparser.cpp ../src/rpi/idchecker.cpp ../src/rpi/eventoperator.cpp -o ../bin/main -lcurl -ljsoncpp
On the Windows system i tried it with a command like this:
arm-linux-gnueabihf-g++.exe -std=c++11 ../src/rpi/main.cpp ../src/rpi/connection.cpp ../src/rpi/jsonparser.cpp ../src/rpi/idchecker.cpp ../src/rpi/eventoperator.cpp -o ../bin/main -L"C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/include/jsoncpp/json/" -L"C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/include/arm-linux-gnueabihf/curl/" -lcurl -ljsoncpp
So i read that i have to tell the compiler/linker where the libraries are, but i don't really understand why since it works perfectly without the -L flag on the Raspi. I think i put the libraries in the same folder as on the Raspi, so i don't understand why they are not found. I hope someone can help me ore give me some short basic explanation on how this stuff works, cause i don't find any working tutorial or other helpful questions for my problem.
On raspberry-pi the libraries are most likely to be linked from system directory like /usr/lib or /usr/local/lib. On Windows, you need to specify the correct path(s) with -L flag.

c++ Makefile doesn't find library

i want to run a "make" command in linux terminal in order to use some c++ libs.
Unluckily while running the "make" an error appears saying it cannot find the requested libs.
Here the relevant makefiles:
Here are the files in my filesystem which should be linked.
Why does makefile not find the libraries ?
Thanks for all answers in advance
Try to modify your Makefile for -lgmp rather than -libgmp
In background the compiler adds the 'lib' onto the name as well as the extension .so and similar stuff.
Try running the following to get an overview of what the linker is trying to do:
ld -L [yourincludepath] -lgmp --verbose
Such resolution issues might be due to the fact you are trying to link a 64bit library with a 32bit application? Try installing a proper XX-bits of the lib maybe?
Try to add -m option (machine dependency):
ld -melf_i386 -L /usr/lib/i386-linux-gnu/ -lgmp --verbose
Other values which might be supported on your side:
elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386linux elf_l1om elf_k1om i386pep i386pe
More info:
usr/bin/ld: cannot find -l<nameOfTheLibrary>

Compiling C++ with g++ -m32 option

I am trying to compile as this :
-bash-4.1$ g++ -static -m32 Hello.cpp
and getting errors like this:
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libstdc++.a when searching for -lstdc++
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
I have tried this as well but still get the exact same error above:
g++ -static -m32 -L/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32 Hello.cpp
I have tried in both orders - nothing helps.
Why is it still looking at the wrong directory?
Is using -m32 option override -L option?
I could not find much documentation on -m32 option.
Please help.
Thanks!
Why is it still looking at the wrong directory?
Compiler always looking in predefined directories first. -L options adds your path to these list of directories, so because of it compiler is stil looking at the wrong directory. For more detailed output try to compiler your program with detailed output -### or -v options.
Is using -m32 option override -L option?
The answer is no - -m32 options is option to generate 32bit code, for example:
You may generate 32bit code that will work on 32bit machine, on your 64bit machine. Also you may run this code on your 64bit machine - it will work well.
I could not find much documentation on -m32 option.
Here is the link to the GCC docs
And here is doc about directory searching options
Also to say to compiler where to find libraries, you may set
LD_LIBRARY_PATH in your env
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FULL_PATH_TO_YOUR_LIB
Do not override env vars - cause it may cause more problems if you are not absolutely sure in what you are doing.

Facebook warpdrive build - D Programming language

Of late, facebook opensourced warp, C/C++ preprocessor.
https://github.com/facebook/warp
I'm trying to build it using dmd and stuck with some build errors.
I downloaded dmd.2.065.0.zip for dmd compiler - dmd2/linux/bin64/dmd
I also see a bunch of libraries, for example libphobos2.a
Then when I build warp, I see some errors from ld, that keep complaining that phobos2.a could not be found. I exported LD_LIBRARY_PATH to the dir where this library is stored but no luck.
I compiled in verbose mode, and it doesn't give more info.
Command:
/path/to//building_stuff/dmd2/linux/bin64/dmd -O -inline -release -ofwarp cmdline.d constexpr.d context.d directive.d expanded.d file.d id.d lexer.d loc.d macros.d main.d number.d outdeps.d ranges.d skip.d sources.d stringlit.d textbuf.d -v
Error excerpt:
function textbuf.Textbuf!char.Textbuf.length
function textbuf.Textbuf!char.Textbuf.resize
gcc warp.o -o warp -m64 -L/path/to/building_stuff/dmd2/linux/bin64/../lib64 -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm -lrt
/usr/bin/ld: cannot find -l:libphobos2.a
collect2: ld returned 1 exit status
--- errorlevel 1
I was hoping the D language experts here, or those who know about warp already could give me some hint.
I was not on CentOS, as warp demands. I wonder if that could anyway be the reason.
I was not using gcc 4.7.x as warp demands, but, to me, the library could just not be located doesn't look like a problem from old gcc I have.
I was on redhat5.5 machine with 4.1 gcc.
CentOS is basically a RedHat, so everything should work OK. As people commented, your real problem is the -l:libphobos2.a in your link line. Remember, GNU/Linux allows colons in file-names, so :libphobos2.a is a perfectly valid file, and GNU ld won't find it in the library search paths.
Note that they've added a make file to easy on your compilation, I managed to compile it using "make -j" and only editing the dmd command line in the make.
just rename "libphobos2.a" to "lib:libphobos2.a.a"
I faced a similar problem with ld version 2.17, but with version 2.20 this 'l:<libfilename>' kinda syntax works fine.