i have made a program in vc++ 2010 in win7 but since the submission asked for a unix executable file i got ubuntu and am unable to compile to the program. i give the command:
gcc (filename) -o (submission file)
and i am getting a lot of errors as someone guided me over this site that vc++ code will be entirely supported in ubuntu. Then why is the problem? what is the solution?
also if any ide is needed can i use mu code block of windows for ubuntu as well?
You should be using g++ instead of gcc, also VC++ code may or may not work depending on what the submission is required to do as Windows has different libraries for certain things. Try using g++ instead and edit your errors into the question so we can help better.
Related
So I get a bit confused on the many possibilities here. I have a CMakeLists.txt, which is hopefully all ready to be used. I am using WSL in the Windows Terminal and switching between microsofts cmd.exe and ubuntu wsl terminal on which I want to be able to run the compile command. So on which side do I need to run cmake and what build-files should I generate or what compiler should I use?
Main goal is having a simple compile cmd in vim on wsl, that compiles the exe for windows.
I tried to setup the build files with cmake from the wsl-side with the mingw cross-compiler, but during project setup it failed to find glfw3 configurations, which felt rather weird since it should use windows glfw files anways, right(?)
Next closest try was to create the build files with cmake from the cmd-site with the cl.exe compiler and ninja. That succeeded, but when now running ninja on the wsl side I get a lot of warnings concerning the unknown cmd option \O0 and fatal errors concerning not being able to include simple files like float.h, stdio.h, Windows.h etc. .
All my current search led me to this point, but I am not able to come up with a solution. So I would love to get some help. I want to stick mainly on the linux side, when programming but in the end have an executable for windows.
On a Windows system, currently I'm trying a waf configure on a directory of code, and it spits out the error "could not configure a C compiler."
Now, I'm 100% certain that I have gcc and g++ installed and in my path because when I type gcc --version, it gives me the current version information. (I'm using mingw and the gcc/g++ are in the /bin subdirectory).
In the author's code directory there is a wscript file which looks like
C_COMPILER = 'gcc-4.7'
CPLUSPLUS_COMPILER = 'g++-4.7'
Now, I have tried changing the strings to simply gcc as well as gcc-4.8.1 (since my current version is 4.8.1), but it still says could not configure compiler.
I tried reading one solution on this same site that looks related, but the solution was on ubuntu and trying to work through those commands didn't help
could not configure a c compiler
I'm at the end of my common sense here after making sure I have gcc and g++ installed, trying different strings in the wscript file trying to get it to recognize I have them installed, and could use some help, thanks.
Edit: I've now tried simply deleting the lines in the wscript file where it changes the compiler name, and suddenly waf configure goes through, but the waf build fails saying things like it can't find really basic things like include vector. The output says it's defaulting to msvs (microsoft visual studio) whereas the author says gcc/g++ is needed; maybe this is the issue but how do I get waf configure/build to use g++/gcc as default?
I am trying to compile MatConvNet on Windows 8.1. Since it seems that I need to use the "Makefile" to do that, I downloaded GNUWin Make, which allows to use the make command on Windows. The error I get is the following one:
process_begin: CreateProcess(NULL, C:\Program Files\MATLAB\R2014a\bin\mexext, ...) failed.
while the file C:\Program Files\MATLAB\R2014a\bin\mexext.bat exists.
Do you have any clue on that please?
I also tried to compile MatConvNet on Windows with MinGW and I faced the same error.
Instead, you can try to compile MatConvNet using Visual Studio. It is explained here:
http://blog.csdn.net/zxd675816777/article/details/40075209
With the translation from Chrome browser, it is understandable :)
Thanks to this tutorial, I successfully generated the 4 mexw64 files needed by MatConvNet.
in the new beta-8 we have added new function vl_compilenn which supports compilation on Windows... (no need for Make, plus we've fixed the issues related to msvc compiler). So far it seems to work also for the GPU code...
You can find detail here. Hope that this would help :)
You need to compile it using Visual Studio rather than GNU compiler on Windows. First set up Matlab mex -setup C++ for Visual Studio 2013/2015 and then compile using vl_compilenn function. If you want to compile it for GPU then you need to install CUDA and cudnn as well. Then you can use vl_compilenn('enableGpu', true) to compile it for Windows with GPU support.
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.
I'm having some trouble installing and configuring qt on my vista laptop.
I'm trying to setup a development environment on my laptop where I compile from the command line, because that's how the environment is setup on my university's linux machines, so I don't want to tie myself to some IDE .. (plus, real programmers use the command line!)
I haven't used the command line before for C++ development, it was all MSVC, so now I'm having a bit of trouble.
I'm still using MSVC, but from the command line. I practically have no idea what's going on, I just know that I have to run:
qmake
nmake
to compile my code!
I downloaded the opensource version of qt, and did the configuration, and tried a simple qt application (from a tutorial) and it worked, it compiled and executed pretty much as expected.
Now, when I decided to run another project that uses opengl, I got the following error:
fatal error C1083: Cannot open include file: 'qgl.h': No such file
or directory
I'm not sure where does the compiler look for header files, and I didn't copy any header files anywhere, I assume that configure.exe worked its magic somehow and added the include directory to one or more enviroment variables or to some registery location or whatever other peculier places that the MSVC compiler searches for to find include directories.
However, what I did was search my C:\qt\include\ folder to make sure that qgl.h exists, and sure enough there it was. so why can't nmake find it?
I think the actual solution to this is in your pro file:
QT += opengl
If you want to stay with the command line anyway (plus use it on a linux box later / parallel) I'd suggest at least trying out the MinGW version of Qt. I'm using it regularly, and besides of the non-existance of a GUI it works pretty well. Using MinGW also has the advantage that you can simply download and install the MinGW edition of Qt and don't need to reconfigure or recompile anything.
Also, trying out QtCreator might be interesting. It's still beta and requires the beta Qt 4.5 but it's a nice small IDE that integrates nicely with gcc.
Two potential solutions (they solved issues at my workplace)
Do you have qt include and bin folders in the PATH variable? I think the doc says only one of these is needed, but one of the students had Vista and putting the other in the PATH variable solved a "Cannot open include file" problem.
If you're using MSVC did you run configure and nmake from the Visual Studio command prompt? We had problems when using the bare windows Command Prompt because the VS one adds a lot of temporary environment variables to the configure process.
Good luck
Install the complete Qt SDK for Windows which includes Qt 4.6 SDK, Qt Creator 1.3, and MinGW.
It will also install "Qt Command Prompt" launcher that you can use to build Qt apps from the command line.
I'm sure you're more familiar with MSVC than MinGW, as I do too (I've been using MSVC 6.0 to MSVC# 2008 for developing .NET apps).
But try MinGW with Qt and I think it's better for long term. I do some C++ development on Linux too so getting familiar with MinGW will be beneficial for you in cross-platform C++/Qt development.
For more info, see Installation of Qt 4.6 SDK for Windows.
Qmake generates Makefile from *.pro file located in current directory. It has qt path compiled in. Type "qmake -v" to see it. You can't move qt's dir after compiling it. If You haven't moved it, first maybe try to install Qt following instruction from INSTALL file. Good luck.
The opensource version of Qt does not provide profiles (mkspecs in qt terms) so qmake can generate nmake (msvc) compatible makefiles.
You have to use mingw/gcc.