I searched on how to link MPICH2 to Code::Blocks, but couldn't find an understandable solution. (running windows 7 64x bit)
So what I did so far is I downloaded the MPICH2 from windows market,
then I install both the .msi and the .exe.
The mpi didn't functions, so I tried using the link and tools section inside code::blocks. No go.
So I copied the .h and .lib files into the MinGW path and choose the 32x bit files to put in the lib folder because both the MinGW is in the 32x program files and the Target PC that will upload the code into is 32x. (I tried the 64x later, no difference).
So far thats the most optimal thing I did the Code::blocks now complete the syntax and tell me whats the parameters is. It just had a problem with sal.h, so I downloaded that and put it in the header and now only give me errors when ever I use the misodes as in
Example:
if I use MPI_Init(NULL,NULL);,
my console outputs undefined reference toMPI_Init#8'|`
My problem is a particular one and most search results was about either one aspect. So I don't know what to do next.
Keep in mind I am a student and have minimum experience in IDE, Compilers, linkers and programming in general. I am in your care.
Thanks in advance.
Thank you , you just edit my grammar while I was trying to fix my own problem all by myself .
I did it thanks for the help "not" .
so I think the linker and lib didnt sync up automatically when I copied it to the MGW file "weird even thou it was completing the syntax and refused to run when I sent false parameters" so basicly I did .
setting >> compiler.. >> Linker setting > add > "the mpi or msmpi lib dir keep in mind 86x or 64x" .
setting >> compiler.. >> Search Dirctory > add > "the Include dir keep in mind 86x or 64x" .
and thats basicly it it runs now but it doesn't use more than one core "my pc is an i3" so I will update it after I fix that .
Related
I am attempting to set up GTK3 for development on Windows 10 following the instructions on tarnyko.net
using the 64bit 3.6.4 bundle from here. The test program currently builds without errors, using the generated options. When I run the program a dialog appears displaying the error message:
Procedure entry point deflateSetHeader could not be located in the
synamic link library C:\Gtk\bin\libgio-2.0.0.dll
From what I can tell so far, deflateSetHeader is a function in zlib that was not present in older versions - a possible cause for the error. Looking in the header file of zlib that came with Gtk, it lists the function.
I have copies of zlib1 in my Gtk bin dir and MinGW (GCC v7.2.0) bin dir.
I tried swapping the versions between directories, but no joy. Don't have much else in my environment path variable, except for a vanilla Python 3.6 install. Don't have zlib1 in SysWOW64. I tried adding -lzlib1 to my gcc compiler options, but that didn't seem to make a difference. I'm running out of ideas now.
Anyone know what might be causing this?
Found the cause by searching my C drive for zlib and found a copy in
C:\Program Files\Intel\WiFi\bin that was causing the problem.
I'm trying to do this in Windows using Git CMD
C:\Users\Ove\paho>git clone https://github.com/eclipse/paho.mqtt.c.git
C:\Users\Ove\paho>cd org.eclipse.paho.mqtt.c.git
C:\Users\Ove\paho>msbuild "Windows Build\Paho C MQTT APIs.sln" /p:Configuration=Release
I'm stuck at msbuild where it repeats a series of errors:
'openssl/ssl.h': No such file or directory
I've installed openssl and there is an environment variable set up in:
C:\OpenSSL-Win32\bin\openssl.cfg
I've tried adding other systems paths like:
C:\Users\Ove\openssl\include\openssl
which is where ssl.h resides
I've also tried sticking the openssl folder in the paho\src folder locally
but I still get these errors
With this commit you can see what's happened
https://github.com/eclipse/paho.mqtt.c/commit/543e761474e4836162a0f4428323173abf2de5ad#diff-0d89939d72d5bb4940c5f129d135d9f4
Windows and MSVC don't have any kind of a system for locating library headers. So naturally, this codebase has its own system for locating the openssl headers which uses an environment variable.
openssl.cfg looks like openssl's own operational configuration, completely unrelated to building anything.
You say you tried "adding" (what does that mean?) C:\Users\Ove\openssl\include\openssl (to what?) which you say is "where ssl.h" resides. So what? Your compiler error isn't telling you it's missing ssl.h. It's telling you it's missing openssl/ssl.h. Perhaps if you "added" C:\Users\Ove\openssl\include which does contain openssl/ssl.h? But I'm not sure how it would have got there unless you copied it around, making things more confusing for yourself.
I'll tell you what I'd do:
set OpenSSLDir=C:\OpenSSL-Win32\include
Putting the openssl folder in paho\src may have worked, if by "openssl folder" you mean C:\OpenSSL-Win32\include\openssl and not C:\OpenSSL-Win32 -- if the project had done the equivalent of -I., meaning that attempts to #include <openssl/ssl.h> from paho\src\SSLSocket.c could find it at paho\src\openssl\ssl.h. However, you can see, the project hasn't done that. Therefore you could add . as an include path and probably make that solution work; or edit the code to #include "openssl/ssl.h" instead.
I've been excruciatingly verbose here because you need to understand how include paths work before you can drop libraries in on windows and combine them all. There's no magic, just simple rules.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
My problem is that code::blocks error message tells me that it can't find file executable in the search path for gnc gcc compiler. Although, I don't know what that means. Also I typed out some code:
#include <iostream>
using namespace std;
int main(void) {
cout <<"Hello World" <<endl;
return 0;
}
I can't build it or run in code::blocks. What do I need to do?
I went on line but I got some answers that are way over my head. I was able to use code::blocks once before I installed Visual studios express 2013. Visual studios didn't work right either. It kept asking me to repair or uninstall every time I tried to open it. So I deleted it along with code::blocks. Now that I re-installed code::blocks I still can't get to work right.
This problem with compilers is taking up all my time and I can't practice learning programming because I can't get any compiler to work right. I need some help, please.
I'm guessing you've installed Code::Blocks but not installed or set up GCC yet. I'm assuming you're on Windows, based on your comments about Visual Studio; if you're on a different platform, the steps for setting up GCC should be similar but not identical.
First you'll need to download GCC. There are lots and lots of different builds; personally, I use the 64-bit build of TDM-GCC. The setup for this might be a bit more complex than you'd care for, so you can go for the 32-bit version or just grab a preconfigured Code::Blocks/TDM-GCC setup here.
Once your setup is done, go ahead and launch Code::Blocks. You don't need to create a project or write any code yet; we're just here to set stuff up or double-check your setup, depending on how you opted to install GCC.
Go into the Settings menu, then select Global compiler settings in the sidebar, and select the Toolchain executables tab. Make sure the Compiler's installation directory textbox matches the folder you installed GCC into. For me, this is C:\TDM-GCC-64. Your path will vary, and this is completely fine; just make sure the path in the textbox is the same as the path you installed to. Pay careful attention to the warning note Code::Blocks shows: this folder must have a bin subfolder which will contain all the relevant GCC executables. If you look into the folder the textbox shows and there isn't a bin subfolder there, you probably have the wrong installation folder specified.
Now, in that same Toolchain executables screen, go through the individual Program Files boxes one by one and verify that the filenames shown in each are correct. You'll want some variation of the following:
C compiler: gcc.exe (mine shows x86_64-w64-mingw32-gcc.exe)
C++ compiler: g++.exe (mine shows x86_64-w64-mingw32-g++.exe)
Linker for dynamic libs: g++.exe (mine shows x86_64-w64-mingw32-g++.exe)
Linker for static libs: gcc-ar.exe (mine shows x86_64-w64-mingw32-gcc-ar.exe)
Debugger: GDB/CDB debugger: Default
Resource compiler: windres.exe (mine shows windres.exe)
Make program: make.exe (mine shows mingw32-make.exe)
Again, note that all of these files are in the bin subfolder of the folder shown in the Compiler installation folder box - if you can't find these files, you probably have the wrong folder specified. It's okay if the filenames aren't a perfect match, though; different GCC builds might have differently prefixed filenames, as you can see from my setup.
Once you're done with all that, go ahead and click OK. You can restart Code::Blocks if you'd like, just to confirm the changes will stick even if there's a crash (I've had occasional glitches where Code::Blocks will crash and forget any settings changed since the last launch).
Now, you should be all set. Go ahead and try your little section of code again. You'll want int main(void) to be int main(), but everything else looks good. Try building and running it and see what happens. It should run successfully.
Just open your setting->compiler and click on the reset defaults and it will start work.
* How to Download and install CodeBlocks.* ( I have already downloaded )
***How to solve the CodeBlocks environment error.
Go to "Settings"----"Compiler"----"Selected compiler"( GNU GCC Compiler ).
Then, Selected "Toolchain executables".
Now, "( C:\Program Files (x86)\CodeBlocks\MinGW )"
See Video : https://youtu.be/Tb1VnXs60Lg
I had also found this error but I have solved this problem by easy steps. If you want to solve this problem follow these steps:
Step 1: First start code block
Step 2: Go to menu bar and click on the Setting menu
Step 3: After that click on the Compiler option
Step 4: Now, a pop up window will be opened. In this window, select "GNU GCC COMPILER"
Step 5: Now go to the toolchain executables tab and select the compiler installation directory like (C:\Program Files (x86)\CodeBlocks\MinGW\bin)
Step 6: Click on the Ok.
Now you can remove this error by follow these steps. Sometimes you don't need to select bin folder. You need to select only (C:\Program Files (x86)\CodeBlocks\MinGW) this path but some system doesn't work this path. That's why you have to select path from C:/ to bin folder.
Thank you.
For that you need to install binary of GNU GCC compiler, which comes with MinGW package. You can download MinGW( and put it under C:/ ) and later you have to download gnu -c, c++ related Binaries, so select required package and install them(in the MinGW ). Then in the Code::Blocks, go to Setting, Compiler, ToolChain Executable. In that you will find Path, there set C:/MinGW.
Then mentioned error will be vanished.
Uninstall/Remove your current codeblocks compiler.
Install codeblocks using this link that contains GCC compiler files: http://sourceforge.net/projects/codeblocks/files/Binaries/13.12/Windows/codeblocks-13.12mingw-setup-TDM-GCC-481.exe.
Now go to : Settings > Compiler.... > ToolChain Executables Tab
CLICK on Auto-detect button and then click OK button. Now just restart CodeBlocks and start writing your codes and use the Build and run option. It will RUN normally.
Fistly, Code Blocks is not a compiler. It is just an integrated development environment.
So, you must show the path of your compiler at first, (if you dont have a compiler you have to download an install, it is not difficult to find. f.e. GCC is good one.)
If code blocks could not find automatically the path of compiler it is an obligation to show it yourself.
But when you install, probably Code Blocks automatically find your compiler.
Enjoy.
This simple in below solution worked for me.
http://forums.codeblocks.org/index.php?topic=17336.0
I had a similar problem. Please note I'm a total n00b in C++ and IDE's but heres what I did (after some research)
So of course I downloaded the version that came with the compiler and it didn't work. Heres what I did:
1) go to settings in the upper part
2) click compiler
3) choose reset to defaults.
Hopefully this works
I'm a total noob but I reinstalled over the codeblocks giving me these "Can't find file executable in your configured search path for gnc gcc compiler" errors by downloading:
codeblocks-20.03mingw-setup.exe
(IMPORTANT: make sure it has the "mingw" in the file download name, that has the compiler build that is required to compile the code which doesn't automatically comes with the main codeblocks editor software download because codeblocks already assumes you already have another compiler installed on your computer {visual studio 2019 or such}).
Then when I created a new project (console application) and used the defaults to quickly test it out.
It gave me errors.
So I went to Settings > Compiler > Selected Compiler set to: GNU GCC Compiler > Click on the "Tooolchain executables" tab > Click on Auto-Detect > Should say "C:\Progam Files\CodeBlocks\MinGW" > Click OK.
Build and run a simple hello world code.
Should work! If not, look for the "MingGW" in the C:\Program Files\CodeBlocks and select it.
Here's an easy way for Windows users.
Uninstall the existing codeblocks from your system.
Restart system.
Go to http://www.codeblocks.org/downloads/26
Download the codeblocks-16.01mingw-setup.exe file. It includes the GCC/G++ compiler and GDB debugger from TDM-GCC (version 4.9.2, 32 bit, SJLJ).
I'm trying to get Bison to do it's thing in VC6. I'm sure this must be a problem with my configuration. At the moment I have a Custom Build step as follows.
<Commands>
echo Start parser generation
"C:\GnuWin32\bin\bison.exe" $(InputPath)
echo Finish parser generation
<Outputs>
$(ProjDir)\$(InputName).c
$(ProjDir)\$(InputName).h
The error I get is "C:\GnuWin32\bin\bison.exe: m4: No such file or directory", which makes me think the m4.exe doesn't exist or isn't on the path, but I can run the exact same command from CMD in the same directory with no errors.
This thought process makes me think it's a problem with the output options, but I've tried various configurations with no luck.
Any help would be great, thanks in advance.
Edit: I've added some more visual studio versions to the tag list to try to get some more exposure for the question. Hopefully someone will have done this in a later version and I can work backwards.
Okay, I've managed to slove this in a very round-about way but I will try my best to document it here.
It seems that VC6 Custom build options will only look in the project directory for the m4.exe, even when you specify where the calling exe (bison) is explicitly. To solve this I did a bit of a hack and did a full cd command in the custom build window to get to the gnuwin32 directory (where both bison and m4 live) before trying to call the parser generator.
This works fine but is a bit of a hassle for trying to distribute it to other people when they may have installed GNU tools to a different location.