Linker can't find mathgl library - c++

I try to make mathgl work, but the linker can't find the library. I installed it through the user repository from arch linux.
I just copied the example program:
#include <mgl2/mgl.h>
int main()
{
mglGraph gr;
gr.FPlot("sin(pi*x)");
gr.WriteFrame("test.png");
}
The official website states you need to link lmgl, but I get this error:
$ g++ main.cpp -lmgl
/usr/bin/ld: cannot find -lmgl
collect2: error: ld returned 1 exit status
I couldn't figure out where to start looking for the library. How can I see where it was installed?
I was looking for libmgl with ldconfig -p getting these results:
$ ldconfig -p | grep libmgl
libmgl2.so.7.5.0 (libc6,x86-64) => /usr/lib/libmgl2.so.7.5.0
libmgl2.so (libc6,x86-64) => /usr/lib/libmgl2.so
libmgl2-qt5.so.7.5.0 (libc6,x86-64) => /usr/lib/libmgl2-qt5.so.7.5.0
libmgl2-qt5.so (libc6,x86-64) => /usr/lib/libmgl2-qt5.so
libmgl2-qt.so.7.5.0 (libc6,x86-64) => /usr/lib/libmgl2-qt.so.7.5.0
libmgl2-qt.so (libc6,x86-64) => /usr/lib/libmgl2-qt.so
libmgl2-glut.so.7.5.0 (libc6,x86-64) => /usr/lib/libmgl2-glut.so.7.5.0
libmgl2-glut.so (libc6,x86-64) => /usr/lib/libmgl2-glut.so

As Amadeus indicated, using
$ g++ main.cpp -lmgl2
should work.

Related

How to configure CMake/CMakeLists.txt to link generic shared library filename rather than the specific one

I have an application configured using CMake and build with GCC. I'm building on one Linux system and try to run it on another. Unfortunately both systems supply different versions of the same lib. For example GLEW, so whenever I try to run executable on the second system I'm getting this:
./app
./app: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory
Here are relevant outputs of app reference and what I have in my system.
ldd ./app | awk '{print $1}' | grep GLEW
libGLEW.so.2.0
ldconfig -p | grep GLEW
libGLEW.so.2.2 (libc6,x86-64) => /usr/lib/libGLEW.so.2.2
libGLEW.so.2.2 (ELF) => /usr/lib32/libGLEW.so.2.2
libGLEW.so.2.1 (libc6,x86-64) => /usr/lib/libGLEW.so.2.1
libGLEW.so (libc6,x86-64) => /usr/lib/libGLEW.so
libGLEW.so (ELF) => /usr/lib32/libGLEW.so
I actually would like to configure CMake or whatever to reference the "least common denominator" filename, so instead of libGLEW.so.2.0 it should ref to libGLEW.so
[EDIT]
Some additional outputs from the builder OS:
cat CMakeCache.txt | grep GLEW
...
GLEW_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libGLEW.so
...
ls -al /usr/lib/x86_64-linux-gnu/libGLEW.so
lrwxrwxrwx 1 root root 16 Jan 12 2019 /usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.2.1.0
So basically CMake gets it right, but then the GCC linker follows the link and actually places a version specific filename as a reference.
In this case I would instruct cmake to link against the shared library generic name, which should be libGLEW.so or similar and be a symbolic link to a specific version of the library. Check in /usr/lib. If it does not exist on the build machine or the execution machine, you may need to create it. However, note that there may not be binary compatibility between two versions of libGLEW, as #AlanBirtles pointed out.
As of cmake 3.15 there is now a cmake module to find glew and handle this better.
Here is a link to the module:
https://cmake.org/cmake/help/latest/module/FindGLEW.html?highlight=glew
You should be able to figure it out from there.
For now I have converged on using patchelf. The solution is based on How can I change the filename of a shared library after building a program that depends on it?
Install patchelf on your linux build host. In my case it's ubuntu,
so apt-get install -y patchelf
Check the app dependencies: patchelf --print-needed ./app, which in my case yields:
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so.2.1
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
Next replace the links to all missing libraries. In my case it was only libGLEW.so.2.1, so patchelf --replace-needed libGLEW.so.2.1 libGLEW.so ./app
Now re-verify of the list of linked libs: patchelf --print-needed ./app
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
Note libGLEW.so.2.1 got changed into libGLEW.so
P.S. I don't consider this a proper solution, so any suggestions how to handle linking properly in the first place are more than welcome.

How to uninstall older versions of libcrypro library

I am trying to link the Unified Automation c++ OPCUA Stack to my project, but I am getting the warning :
libcrypto.so.1.1, needed by libuastackd.so, may conflict with libcrypto.so.1.0.0
Followed by the error:
:-1: error: libuapkicppd.a(uapkicertificate.cpp.o): undefined reference to symbol 'OPENSSL_sk_num##OPENSSL_1_1_0'
From the command prompt, ldconfig on the shared libraries returns:
craig#craig-B250-HD3P:~$ ldconfig -p | grep libssl
libssl3.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl3.so
libssl.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so
craig#craig-B250-HD3P:~$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
libcrypto++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto++.so.6
craig#craig-B250-HD3P:~$
Can I safely delete libssl.so.1.0.0 (libc6,x86-64) and libcrypto.so.1.0.0?

How to resolve warning /usr/bin/ld: warning: libtiff.so.4, needed by /home/user/libs/opencv/lib/libopencv_highgui.so, may conflict with libtiff.so.5?

Some C++ project use TIFF library and OpenCV library at the same time.
The following warning is produced:
/usr/bin/ld: warning: libtiff.so.4, needed by /home/user/libs/opencv/lib/libopencv_highgui.so, may conflict with libtiff.so.5,
How can it be resolved?
If it matters I'm using Ubuntu and Eclipse.
/sbin/ldconfig -p > libs.txt show me
libtiffxx.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libtiffxx.so.0
libtiffxx.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libtiffxx.so
libtiff.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libtiff.so.4
libtiff.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libtiff.so
libopencv_highgui.so.2.4 (libc6,x86-64) => /usr/local/lib/libopencv_highgui.so.2.4
libopencv_highgui.so.2.3 (libc6,x86-64) => /usr/lib/libopencv_highgui.so.2.3
libopencv_highgui.so (libc6,x86-64) => /usr/lib/libopencv_highgui.so
But I don't know what it means, different versions of library?
I suggest you try the following:
find a newer version of libopencv_highgui.so compiled with libtiff.so.5
recompile libopencv_highgui.so with libtiff.so.5
delete libtiff.so.4 and make a symlink to libtiff.so.5 if you get a linker error

Compiling OpenGL Program (Linux) - Cannot find -lGL

I am attempting to compile a test opengl program on ubuntu. I have installed bumblebee, the nvidia 304 driver and libgl1-mesa-dev, using apt-get.
I can see the file /usr/lib/libGL.so.1 - and yet compiling with g++ and the flag -lGL returns the error: error: cannot find -lGL.
Any ideas on what I can do to fix this?
Output of dpkg -L libgl1-mesa-dev
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/libgl1-mesa-dev
/usr/share/bug/libgl1-mesa-dev/script
/usr/share/bug/libgl1-mesa-dev/control
/usr/share/doc
/usr/share/doc/libgl1-mesa-dev
/usr/share/doc/libgl1-mesa-dev/copyright
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/gl.pc
/usr/share/doc/libgl1-mesa-dev/changelog.Debian.gz
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
/usr/lib/x86_64-linux-gnu/libGL.so
/usr/lib/x86_64-linux-gnu/libglapi.so
Update
The command ldconfig -p | grep libGL.so gives the output:
libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/lib/libGL.so.1
libGL.so.1 (libc6) => /usr/lib/i386-linux-gnu/libGL.so.1
libGL.so (libc6) => /usr/lib/i386-linux-gnu/libGL.so
I don't know if that's useful or correct?

Linux: C++: /usr/bin/ld: cannot find -llibboost_serialization

When I try to build some application with linking boost's library libboost_serialization.so, I have this error message:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: cannot find -llibboost_serialization
collect2: ld returned 1 exit status
This is the output from ldconfig:
linux-rxa13:/usr/lib64 # ldconfig -p | grep serialization
libboost_wserialization.so.1.46.1 (libc6,x86-64) => /usr/lib64/libboost_wserialization.so.1.46.1
libboost_wserialization.so (libc6,x86-64) => /usr/lib64/libboost_wserialization.so
libboost_serialization.so.1.46.1 (libc6,x86-64) => /usr/lib64/libboost_serialization.so.1.46.1
libboost_serialization.so (libc6,x86-64) => /usr/lib64/libboost_serialization.so
And this is command line to build test application:
g++ -o "m" m.o -L/usr/lib64 -llibboost_serialization
I've searched for the solution to this problem, but I haven't found it. Thanks!
Don't put in the lib: -lboost_serialization
I removed the "lib" from -llibboost_serialization and that worked for me. So it ended up being:
-lboost_serialization