I am using the follows
1) VS 2010 C++
2) Debug Win 32
3) The library from here
http://www.hdfgroup.org/HDF5/release/obtain5.html
Basically I downloaded Windows (32-bit) Compilers: CMake VS 2010 C, C++, IVF 12, RWDI and installed it. I tried to include a sample code in my C++ application and ran into the following
***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.12, library is 1.8.11
SUMMARY OF THE HDF5 CONFIGURATION
=================================
General Information:
-------------------
HDF5 Version: 1.8.11
Configured on:
Configured by: Visual Studio 9 2008
Configure mode: CMAKE 2.8.11.2
Host system: Windows-6.1
Uname information: Windows
Byte sex: little-endian
Libraries:
Installation point: J:/dev/opt/hdf5-1.8.11
You either have two versions of HDF5 installed and you are compiling with one (1.8.12) but linking with the other (1.8.11 in J:/dev/opt/hdf5-1.8.11), or more likely you installed HDF5, compiled your program, then updated HDF5 later on and didn't clean some object files in your project…
First try to Clean All and Build your program again, it might be enough.
If this doesn't work, find out if you have two versions installed at the same time and remove one of them if this is the case, Clean All and Build your program.
If this doesn't work, remove all HDF5 stuff on your system and reinstall the HDF5 library, Clean All and Build your program.
I have the same problem and I solved the issue by using
conda install -c anaconda hdf5=1.8.12
I hope this will work with you too
This seems to show up for only when the application(using Theano+Keras+Anaconda) is run using PyCharm in Windows machine.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting the HDF5_DISABLE_VERSION_CHECK=1 suppresses it.
Related
EDIT 1
This seems to be related to linking to the mono library, once I remove any kind of reference to mono code and remove the linking to the library from my CMakeList.txt file, debugging works as expected.
EDIT 2
Okay, I've discovered something interesting. This actually might not have anything to do with how I am linking libraries, it appears to be directly related to how I am initialising a class in my unit test. For whatever reason, if I use my normal syntax of TypeDeclaration variableName; the unit test fails immediately with the error code 0xc0000135, but if I change it to read TypeDeclaration variableName(); the code will run. Only problem is that I then get a warning stating empty parenthesis interpreted as a function declaration. I came from linux using g++ to compile my code and there was never an issue, now all of a sudden trying to compile on windows using cygwin or mingw means I can't use the normal standard c++ syntax to actually do work...
Edit 3
I've discovered that this issue is occurring because the libraries I am dependent on aren't actually being copied into the build directory of my unit test project. If I manually copy the required libraries into my build directory debugging works as expected, will need to learn how to express this requirement in CMakeList.txt
More Details
CLion Specifics
CLion 2018.3.1
Build #CL-183.4588.63, built on December 5, 2018
JRE: 1.8.0_152-release-1343-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Toolchain Settings
Cygwin 32 bit version 2.11.2
CMake version 3.13.1
Make version 4.2.1
gcc version 7.3.0
Debugger Cygwin GDB version 8.1.1
catch.hpp for unit testing.
Problem
When debugging a unit test, CLion reports the following error:
During startup program exited with code 0xc0000135.
Google returns a lot of Qt and netbeans related results, everyone suggests to add C:\mingw\bin to the system PATH variable. However I am not using mingw I am using cygwin. I tried adding C:\cygwin\bin to my PATH directory but that does not help. I also tried switching toolchain to use mingw to see if that would help. but the same problem occurs with debugging.
Not sure what else I can do to proceed in resolving this one, any ideas would be most welcome.
I am using Eclipse Helios (version 3.6.1, Build id: M20100909-0800) on RHEL 6.9 and created several projects within a workspace that I specified as empty static libraries. After trying to compile each of the projects I got an error stating that it could find main.
I tried the suggestion at Changing Project Type from “Executable” to “Static Library” in Eclipse CDT but my Build Artifacts Artifact Type only included Executable and Shared Library. Unfortunately I can't used a shared library on some of my libraries because they end up loading more shared libraries (depending on installation location).
My problem is that I don't have an option for Static Library as an Artifact Type. Could this be some kind of configuration issue with Eclipse? Unfortunately, I don't have the ability to upgrade (easily - if at all), but I may be able to get someone to fix the installation if that is indeed the issue.
For those coming to this question after a recent install of RHEL 8 (in 2022) the solution is the same, upgrade Eclipse. I had the same problem which was solved when Eclipse was upgraded to 2021-12. This has to be done manually since the upgrade function in the Eclipse disto that comes with RHEL 8 doesn't work.
I am new to Linux programming and I wonder, is there a way to run (not recompile) my C++ executable on an older version of Linux of the same distribution?
Example: Say I compiled my code on RHEL 6 and want to run my executable on RHEL 4 or 5.
In Windows when we do this we just install the C++ runtime of the compiler version of C++.
Example: If I use VS2012 to build a C++ project using C++11, I just need to install the C++ runtime of C++11 on the client machine to run my application no matter what version of Windows I am using (of course starting from Windows XP)
The by far easiest way is to make use of the strong future compatibility of glibc and the GCC runtime libraries: compile your executable on the oldest OS you want it to run on, and it should work on anything later without recompiling (that is, some symlinks may be needed to satisfy the dependencies the executable loader is expecting).
In general it is best to compile it for each distribution you want to support, so no unexpected conflicts appear.
Actually, yes - Find your apps deps (using e.g: ldd) and copy them (e.g: libstdc++.so.6) from your build system to somewhere on your target system (e.g: /mylibs). Point your app here (e.g: using patchelf's --rpath and --interpreter). Your app should run (test it!). If not, it's likely that your glibc is incompatible with the older kernel. You can solve this by recompiling the required version of glibc to support the older kernel - using the --enable-kernel=<version> ./configure switch. If your required version of glibc doesn't support that kernel version then you can supply the missing functions in .so's and load them with LD_PRELOAD.
Can g++ and minGW on Windows XP use the Windows SDK?
Specifically, why does g++ fail to compile:
#include <stdio.h>
#include <windows.h>
int main(void) {
printf("!!!Hello World!!!");
return EXIT_SUCCESS;
}
I have tried compiling by by running:
g++ -c -Wall Test.cpp -IC:/Program\ Files/Microsoft\ Platform\ SDK/Include/
I get a litany of compile errors beginning with
winnt.h:666:2: #error Must define a target architecture.
I have installed the Windows Server 2003 SP1 Platform SDK
Background
I am working on a large real-time image processing software project that up until now has used g++, minGW and gnu make files (written by hand). For a new feature, I need to interface with a frame grabber that has an SDK which was designed for Visual Studio. The framegrabber SDK depends on header files from the Windows SDK.
Do I need to learn Visual Studio or is there another way?
I use MinGW to compile Windows programs every day, with zero problems. There must be something wrong with your installation - try the version at Twilight Dragon Media.
Edit: Just re-read your post - you do not need to specify the include directory as you are doing, and probably should not do so. Also, you may (or may not) need the slightly mysterious -mwindows flag. I just compiled your program using MinGW (TDM build) g++ 4.4.1, with the command line:
g++ main.cpp
with absolutely no problems.
More Info: Just so you know what the -mwindows flag does, the GCC docs say:
This option is available for Cygwin and
MinGW targets.It specifes that a GUI
application is to be generated by
instructing the linker to set the
PE header subsystem type appropriately.
Personally, I've never found it necessary, but then my Windows apps are all command line tools or servers.
According to the discussions from the MinGW-users mailing list, you might encounter compatibility problems with the Windows SDK, and you may have to fix those problems yourself.
Georgi Petrov [Dec 27, 2010; 8:33am]:
Hello,
I'm trying to develop a EVR (Vista/7 specific video presentation API)
renderer for MPlayer on MSYS/MinGW. The problem is that I have Windows
SDK v7.1 and I need evr.h from it. If I try to copy it to MinGW's
include directory as well as the 12 header files it includes, the
compilation is close to impossible. I have a TON of errors just by
including evr.h, nothing else. I investigated and found that I can't
use the Windows SDK header files directly with MinGW, because it ships
with its own header files, which are sometimes very, very different.
The problem is that Media Foundation/Enhanced Video Renderer header
files are not part of MinGW's header files.
What should I do?
Windows SDK header files question:
http://mingw-users.1079350.n2.nabble.com/Windows-SDK-header-files-question-td5870336.html
Ross Ridge [Oct 10, 2010; 10:16pm]:
For the most part the Windows SDK headers aren't incompatible with
GCC. If there one particular header file you need that doesn't exist
in win32api heapers or is missing something you need, then you can
try just using that one header with from the Windows SDK and use
win32api for the rest.
It's also possible to only use Windows SDK headers, and avoid using
the win32api headers entirely, but you need to fix a number of
problems in key header files. I used to just modify the headers, but
the Windows SDK has actually gotten a bit more compatible and now I
use wrappers to fix the problems.
There are some header files and libraries that are pretty much
fundementally incompatible with GCC, like GDI+. If you want to use
GDI+, you'll need to use a Microsoft compiler.
Ross Ridge
compiling against Windows SDK:
http://mingw-users.1079350.n2.nabble.com/compiling-against-Windows-SDK-td5609389.html
try adding these defines before you include those windows headers
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
EDIT: my gcc compiles your script without problems (and without these defines) aswell.
I am using mingw's gcc 4.40 (alpha ?!)
Try using the latest version of MSYS2 UCRT64 with MingW64. I'm using it on Windows 11.
Use 'pacman' to install 'mingw-w64-x86_64-gcc'. Try re-installing it too to insure you have the WIN32 SDK which is included in this windows-based package:
$ pacman -S mingw-w64-x86_64-gcc
warning: mingw-w64-x86_64-gcc-12.2.0-6 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) mingw-w64-x86_64-gcc-12.2.0-6
Total Installed Size: 154.48 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring [###############################] 100%
(1/1) checking package integrity [###############################] 100%
(1/1) loading package files [###############################] 100%
(1/1) checking for file conflicts [###############################] 100%
(1/1) checking available disk space [###############################] 100%
:: Processing package changes...
(1/1) reinstalling mingw-w64-x86_64-gcc [###############################] 100%
I discovered the windows.h is located in '/ucrt64/include' within the shell session and 'C:\Msys64\ucrt64\include' outside the shell:
$ find . -name windows.h
./mingw64/include/windows.h
./ucrt64/include/windows.h
Here's a link to an article from Microsoft which shows how to troubleshoot setting up gcc to work with building windows applications:
https://code.visualstudio.com/docs/cpp/config-mingw
You can add the directories to your build using the '-I' parameter on 'make' or 'gcc':
make -I /ucrt64/include
I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.