I installed the flann and libhdf5-serial-dev c++ library on ubuntu. After that, I compiled the flann_example.cpp file without problems. However, when I launched the executable I got the following error message :
Warning! HDF5 library version mismatched error
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.8.16, library is 1.8.7
Bye...
Abandon (core dumped)
I used the following expression to suppress this warning :
cmake -HDF5_DISABLE_VERSION_CHECK=1 -H. -Bbuild
But I still have this message. I looked for the optional flag HDF5_DISABLE_VERSION_CHECK with ccmake to check if it's setting to 1. But I couldn't see this flag.
Someone could help me to solve this issue ?
You can, at your own risk, disable this warning by setting the environment variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
HDF5_DISABLE_VERSION_CHECK is an environment variable, not a compiler #define or CMake variable. Set it within your shell:
export HDF5_DISABLE_VERSION_CHECK=1
path/to/flann_example
or
HDF5_DISABLE_VERSION_CHECK=1 path/to/flann_example
However, you're probably much better off fixing the root problem (the library mismatch). On Ubuntu, if you always install the Ubuntu-packaged versions of libraries (via apt, aptitude, Synaptic...) instead of installing libraries yourself, this should ensure that all library versions are compatible.
Related
Here's my problem:
Trying to debug a C++ program in gdb, but bt won't produce a complete backtrace. It's getting stuck on the Glib shared library, which has been built without any debug info and without -frecord-gcc-switches - this is how it comes as part of the o/s.
I want to build the shared library exactly the same, but with debug info. How can I do this? Building it with Meson shows several other shared libraries and packages that will influence its contents depending on their presence, and there's also of course different compile time flags I can use.
Is there an easy way to ensure the version I build from source produces the same object file as that packaged with linux (plus debug info)?
I've used apt-get source glib2.0-0 and it gives me all the meson files, ninja files and help files I appear to need, but it doesnt quite say this is how it comes as part of Raspberry Pi O/S.
I'm pretty new to C++ and I'm having a hard time trying to install external libraries. I want to get started with GUI programming and I have searched all over, but I cannot find a way to add wxWidgets to Code::Blocks. I've tried a few different guides and Stack Overflow responses but none of them have actually worked.
I'm using this 'Hello World!' test program to see if it works, every time I try to run it I just get this error: fatal error: wx/wxprec.h: No such file or directory. I can't seem to figure out how to tell Code::Blocks where the library is.
The most recent resource I have tried is this one, I followed it step by step, but still I got this error.
What linker/compiler settings do I need to use in Code::Blocks? What lib files do I need to add and where do I add them to? Do I need to build the .zip file? How do I do this?
Please could I get a step by step guide on exactly how to add wxWidgets (or indeed any external library) to Code::Blocks as well as some information on why certain things are required?
Here's what I tried
Following the steps in the link above, this is what I have in my build options:
I tried adding this in my global compiler settings...
I still have this error...
CodeBlocks seems to have some special wxWidgets integration, but it didn't always work for me, so I prefer to set up the project manually.
CB ships an outdated compiler. While it may work, updating it is a good idea.
Get rid of the MinGW version shipped with CB, or at least remove it from the PATH.
Install MSYS2. Use it to install a new GCC and GDB, as described in the link.
Configure CB to use MSYS2's GCC and GDB, by specifying the paths to them in the CB config (they're installed to C:\msys64\mingw64\bin).
wxWidgets seem to ship prebuilt libraries for MinGW, but since we're using MSYS2, we might as well use the version provided by MSYS2.
Use MSYS2 to install wxWidgets: pacman -S mingw-w64-x86_64-wxWidgets3.2-msw.
MSYS2 seems to ship several different versions of wxWidgets: 3.0, 3.1, 3.2, and each of them in two variants: -msw and -gtk. 3.2-msw looks like a reasonable choice to me, but I haven't used this library before.
wxWidgets doesn't seem to use the standard way of telling you what compiler flags to use (which would be pkg-config, or at least a CMake file). Instead they ship their own script to determine the flags, called wx-config.
Run wx-config --cflags to get the compiler flags, and run wx-config --libs to get the linker flags. Paste them into the project settings (compiler settings and linker settings respectively). Edit the project settings, not the global compiler settings.
I have recently upgraded my OS (to PopOS! 22.04) and now a bunch of builds in my cmake workflow aren't compiling, halting at this particular error at the linking stage:
*** No rule to make target '/usr/lib/x86_64-linux-gnu/libdl.so'
This file now no longer exists. There is however a libdl.so.2.
Running apt-file search /usr/lib/x86_64-linux-gnu/libdl.so gives no output.
How can I get my builds working again?
EDIT:
The solution turned out to be due to manually built dependencies/packages that obviously weren't updated during the upgrade. I had to go and rebuild them, and then the error disappeared. Note, when rebuilding them (also with CMake) it required a full deletion of the build directory, not just running CMake again.
Jammy's GNU C Libarry version is 2.35. The dl library is now part of the C standard library. The release notes, tells that, starting from version 2.34,
all functionality formerly
implemented in the libraries libpthread, libdl, libutil, libanl has
been integrated into libc. New applications do not need to link with
-lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility,
empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are
provided, so that the linker options keep working. Applications which
have been linked against glibc 2.33 or earlier continue to load the
corresponding shared objects (which are now empty).
This means that you have to remove the explicit libdl.so from the linker dependencies.
I am having trouble debugging when using gdbserver. gdb shows error loading one of the shared libraries.
Error while mapping shared library sections:
`target:<path to library>': not in executable format: Invalid argument
I have no problem when attaching with gdb using PID. But gdbserver throws the above error and then I am unable to set any breakpoints in that shared lib.
Any idea what could be wrong? I have other libraries from the same application that don't seem to have any problem.
I am running on
Centos 6.7
gdb version 7.11.1
gcc version 4.4.7
I encountered this error in GDB 7.11 (the one that ships with Android's NDK-r20), and it was caused by my library being relatively large (300MB), which tripped a bug in gdbserver's integer parser that prevented gdbserver from loading any library larger than 268MB. The bug got fixed in GDB 8.2, by raising the limit to 2GB (https://sourceware.org/bugzilla/show_bug.cgi?id=23198).
I used GDB's sysroot feature to work around this issue: https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-set-sysroot
I copied the libraries from the remote target to my local system* and used set sysroot sysroot-here (where "sysroot-here" is a directory containing the directories/files that I had copied). This forces GDB to read symbols locally instead of from the target.
With this sysroot approach, I did not only work around the bug, but I was also able to use the library with full debugging symbols (about 3GB, which would probably also have tripped newer GDB versions).
* I copied all system libraries and the app's libraries, while preserving the full directory structure / file paths. I wanted to only copy the specific library that triggered the bug, but with sysroot it is all or nothing: Either all libraries are to be found locally on the host, or none. See also: A way to have GDB load libraries from local sysroot and remote gdbserver
I found that gdb version 7.10+ has this problem with my particular binary. Still not sure why. This works fine with 7.9 so I downgraded to overcome this issue.
While compiling mpich, I got a few relinking warnings...
libtool: warning: relinking 'lib/libmpicxx.la'
I have not been able to find out what these mean by googling the error message. What is relinking? Why is it caused and how can I get rid of it?
The "relinking" warning is emitted when installing, not when compiling. Libtool warns you that it is running a potentially slow command during the install. There may be different reasons for relinking.
In case of mpich, the reason is completely innocuous. The libmpicxx library depends on libmpi library. Both are built from the same source. Libtool ensures that if you run any executable in the build directory, it would use the libraries from the build directory rather than the installed library.
There is no way to make sure (at least on Linux) that libmpicxx would use the locally built libmpi library without hardcoding the library search path (so called RPATH) into libmpicxx.
For the installed libraries, the requirement is that they never refer to the build tree where they were built. So the RPATH needs to be eliminated from the installed libmpicxx library. That is done by relinking it.
Once again, the warning is not about you or the package doing anything wrong, it's about a potentially slow operation at the install stage (slow operations at the build stage are expected and don't need a warning).