I have a GCC OpenMp library (libgomp.so) that doesn't contain any symbol, and I need to either install/compile a new library with symbols or obtain debug information for the library. I found something (lib64gomp1-dbg) in the gcc-5 package, but I'm not sure if this is what I want and I don't know how to install it either (I've tried sudo apt-get lib64gompl-dbg, but it didn't work, it threw the error: E: Invalid operation lib64gompl-dbg). So how can I get debug symbols for the library? I'm fresh new to Linux, can somebody give me a hint on how to do that? Thanks a lot!
You need to use
sudo apt install lib64gompl-dbg
(Note the inclusion of the word install.)
Related
Hi, All
I am currently installing the openmpi-4.1.1 on ubuntu18.04 from the tar.gz file.
However, when I use the nvcc (CUDA 11.2.2) compiler with -lmpi_cxx, it reports that this linking option does not exist.
is there anything wrong when I am building and installing the openmpi?
I use the following commands when building openmpi with CUDA-aware capability.
./configure --with-cuda
make -j8 install
I try to remove -lmpi_cxx and only keep -lmpi, the compiler reports errors like
undefined reference to `MPI::Comm::Comm()'
Thanks a lot!
I just figure this out by myself.
I need to enable the c++ binding of the MPI when building the openmpi.
Here are the commands
./configure --enable-mpi-cxx --with-cuda
make all install
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 have a problem using Paho MQTT client in C.
I downloaded the pre built binaries for my system (Windows 10 64) from their projects page. I unpacked the zip file to a folder in the documents folder, where I also created a .c file with the example at the bottom of the Paho product page. My editor is atom and my compiler is gcc.
When I tried to compile it in Atom, I got this error:
undefined reference to MQTTClient_create'
So I went searching and found plenty of topics, but I still couldn't figure out, how to resolve this issue. From this stackoverflow topic I gather that it's a linker problem and that I need to link the files during compile, so here's what I tried:
gcc MQTT.c -L "C:\Users\Pete\Documents\MQTT on C\Examples\Paho\lib" -l paho-mqtt3c
Which still gives me the same undefined reference error. When I try to link to the dll of the same name, the compiler does not find the file.
Can anyone point me in the right direction, please?
Any help is appreciated!
I'd be interested to know if you have registered the Paho MQTT dll in Windows?
You should have paho-mqtt3c.dll as part of the download.
I don't know if this will work for you, but I have the same issue (undefined reference to MQTTClient_create)...
Copy the dll file into c:/windows/system32
Run CMD Prompt as Administrator and type:
regsvr32 i/ paho-mqtt3c.dll
Worth a try.
The problem was that I was compiling the program with the 32-bit gcc compiler for the 64-bit library. Installing and using MinGW64 worked.
I had the same issue in OS X. This is how I resolved it
I compiled the paho-mqtt library in Linux/EC2 instance.
Installed all the dependencies:
sudo yum install install build-essential gcc make cmake cmake-gui cmake-curses-gui
sudo yum install cmake
sudo yum install doxygen graphviz
cmake -DPAHO_WITH_SSL=TRUE -DPAHO_BUILD_DOCUMENTATION=FALSE -DPAHO_BUILD_STATIC=TRUE -DPAHO_BUILD_SHARED=FALSE -DPAHO_MQTT_C_PATH=../paho.mqtt.c/ -DPAHO_MQTT_C_LIB=../paho.mqtt.c/src/libpaho.mqtt3as-static.a
make
make html
make install
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ec2-user/paho.mqtt.c/src
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
sudo ldconfig
gcc test1.c -o test1 -lpaho-mqtt3c
Compiled successfully..
./test1
This solution works for OS X as well. Replace step 2 with
brew install cmake doxygen openssl-devel
Trying to install fftw to use GADGET2, and after running the following command:
./configure --enable-mpi --enable-type-prefix --enable-float
I get the message:
checking for mpicc... mpicc
checking for MPI_Init... no
checking for MPI_Init in -lmpi... no
checking for MPI_Init in -lmpich... no
configure: error: couldn't find mpi library for --enable-mpi
Now I have installed openMPI already, so it seems to be the case that it just can't find it. There was a similar question posted a while ago with different mpi software. I think the problem is that my openMPI and other compilers might be in different folders? This brings me to a more general question (I have tried googling this but can't find anything that explains it well):
If I extract a tar and use ./configure without any prefix, where will the program install to? And is this is an issue that my openMPI has for some reason installed to a different place?
Thanks!
edit: found a solution for this from this question, where just running
sudo ldconfig
seemed to fix it and now it compiles fine.
I am trying to compile the openlase library from www.marcansoft.com and have been running into problems with CMake. CMake is returning an error stating that it cannot find Curses, and after a lot of looking I am still stumped as to what the issue is. I have checked that I have the various ncurses packages installed but still the error persists. Im not very familiar with CMake but I was able to resolve other dependency issues that arose before this one. The following is the output in terminal.
tom#SILVER:~/dev/openlase$ cmake ./
-- Found JACK
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindCurses.cmake:159 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
examples/27c3_slides/CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
Any help would be greatly appreciated.
Tom
Here is what fixed my problems on Ubuntu 12.04 x86_64 (64 bit) (Thanks syslogic )
For whatever reason (1:00 am maybe?) setting CURSES_USE_NCURSES TRUE didn't seem to work. So I went with a hack job.
Verified it's installed:
$ sudo apt-get install libncurses5-dev
You will see something to the effect: libncurses5-dev is already the newest version.
So find the library and include.
$ locate libncurses.so
Note location, mine: /usr/lib/x86_64-linux-gnu/libncurses.so
$ locate curses.h
Note location again, mine:
/usr/include
In: <cmake source dir>/Modules/FindCurses.cmake
add at the top, right after the comments
set( CMAKE_INCLUDE_PATH "/usr/include")
set( CMAKE_LIBRARY_PATH "/usr/lib/x86_64-linux-gnu/libncurses.so")
then rinse repeat the build process
./bootstrap
make
sudo make install
ccmake should now be installed.
Your pal,
Another way to fix it is to add these 2 lines to FindCurses.cmake (on top):
set(CURSES_LIBRARY "/opt/lib/libncurses.so")
set(CURSES_INCLUDE_PATH "/opt/include")
Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
Do you have the corresponding -dev package installed too? On Ubuntu (and probably anything derived from Debian) it is libncurses5-dev. Other systems may use -devel or similar tags.
The compiler is looking for the library headers, and those aren't provided by the standard package. (The headers aren't needed at runtime, only when compiling software, so they make it easy to remove extra useless stuff for systems that aren't going to be doing any software compiling.)
The openlase wiki was not displaying all of the needed packages. Check there wiki pages on github for updated instructions. For curses the missing package was libncurses5-dev sudo apt-get install libncurses5-dev
Temporarily set CURSES_NEED_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
set(CURSES_NEED_NCURSES TRUE)
CURSES_USE_NCURSES is used by FindCurses.cmake internally, so setting that won't help.