I've been trying to find a solution for my problem for a while now.
I am trying to use gcc to compile my c programs on Windows 7.
My current code
set makeprg=gcc\ %\
gives me "gcc: error: missing filename after '-o'.
How can I get rid of this error?
If your gnumake program is correctly configured (linux, cygwin, ...), but unfortunately not with mingw, you don't need to tweak :makeprg for mono-files pet project compiled where the source files are.
In those cases, if you need to add options, just set them into $CXXFLAGS, $LDFLAGS, $CFLAGS, $CC, $CXX, etc. from vim:
:let $CXXFLAGS='-g -O2 -std=c++11'
Now, back to your problem (as I suspect the badly configured mingw), I'm not sure why you have a backslash at the end of your expression. I'd have used (a plugin, but this is a different story):
" in a c ftplugin/ or a local vimrc in the directory where C pet projects are
:setlocal makeprg=gcc\ %\ -o\ %<.exe
Related
Currently I am using Clion IDE plus latest version of Open Watcom v2 windows 32 bit compiler to develop some 16 bit MS-DOS application. The problem I have is I don't see all required debugging information when using watcom windows debugger (wdw.exe).
Being specific, I see global variables, global and any other types of functions, even those imported from asm files. But well, local variables list is empty all the time. But more importantly - the only c-code I can see is little test.c file which contains only main() function and nothing else except for includes.
What do I need to do to finally get c-level debugging for whole project? What am I missing?
I would be grateful for any help.
All source files is located in one directory, so, they all should be visible to debugger. But it sees only main c file.
Of course I am compiling with -d2 switch, as well as -hw. DEBUG WATCOM ALL is also presented in linker config file before any FILE directives. Reading manuals to compiler and linker... Well, it's nice that I've found many interesting things in manuals, but nothing helped with exactly that issue so far :)
List of compiler switches I currently using:
WCC.EXE:
CALL WCC.EXE -dTEST -bt=dos -0 -za99 -wx -we -mc -zp2 -hw -d2
%SRC_FULL_NAME%
WLINK:
CALL WLINK.EXE #..\CC.LK
CC.LK:
SYSTEM DOS
DEBUG WATCOM ALL
FILE TEST.OBJ
FILE LUTILS.OBJ
FILE LGL.OBJ
NAME TEST.EXE
OPTION ELIMINATE
...
I want to run serial commands from a Bealgebone to a 4Dsystems display. Therefore I copied the c library found here into a directory and created a test program main.c:
#include "Picaso_const4D.h"
#include "Picaso_Serial_4DLibrary.h"
int main(int argc,char *argv[])
{
OpenComm("/dev/ttyUSB0", B115200); // Matches with the display "Comms" rate
gfx_BGcolour(0xFFFF);
gfx_Cls();
gfx_CircleFilled(120,160,80,BLUE);
while (1) {}
}
Now when I do gcc -o main main.c its says
main.c:2:37: fatal error: Picaso_Serial_4DLibrary.h: No such file or
directory
So I try linking it:
gcc main.c -L. -lPICASO_SERIAL_4DLIBRARY
which gives me the same error. Then I tried to create a static library:
gcc -Wall -g -c -o PICASO_SERIAL_4DLIBRARY PICASO_SERIAL_4DLIBRARY.C
which gives me this:
PICASO_SERIAL_4DLIBRARY.C:1:21: fatal error: windows.h: No such file
or directory compilation terminated.
What am I doing wrong? the git page clearly says this library is created for people who do not run windows.
Thanks in advance!
You're not getting a linker error; you're getting a preprocessor error. Specifically, your preprocessor can't find Picaso_Serial_4DLibrary.h. Make sure that it's in your include path; you can add directories to your include path using the -I argument to gcc.
You've had two problems. First was the picaso_whatever.h file that couldn't be found. You fixed that with the -I you added. But, now, the picaso.h wants windows.h
What are you building on? WinX or BSD/Linux?
If you're compiling on WinX, you need to install the "platform sdk" for visual studio.
If you're using mingw or cygwin, you need to do something else.
If on WinX, cd to the C: directory. Do find . -type f -name windows.h and add a -I for the containing directory.
If under Linux, repeat the find at the source tree top level. Otherwise, there is probably some compatibility cross-build library that you need to install.
Or, you'll have to find WinX that has it as Picaso clearly includes it. You could try commenting out one or more of the #include's for it and see if things are better or worse.
If you can't find a real one, create an empty windows.h and add -I to it and see how bad [or good] things are.
You may need the mingw cross-compiler. See https://forums.wxwidgets.org/viewtopic.php?t=7729
UPDATE:
Okay ... Wow ... You are on the right track and close, but this is, IMO, ugly WinX stuff.
The primary need of Picaso is getting a serial comm port connection, so the need from within windows.h is [thankfully] minimal. It needs basic boilerplate definitions for WORD, DWORD, etc.
mingw or cygwin will provide their own copies of windows.h. These are "clean room" reimplementations, so no copyright issues.
mingw is a collection of compile/build tools that let you use gcc/ld/make build utilities.
cygwin is more like: I'd like a complete shell-like environment similar to BSD/Linux. You get bash, ls, gcc, tar, and just about any GNU utility you want.
Caveat: I use cygwin, but have never used mingw. The mingw version of windows.h [and a suite of .h files that it includes underneath], being open source, can be reused by other projects (e.g. cygwin, wine).
Under Linux, wine (windows emulator) is a program/suite that attempts to allow you to run WinX binaries under Linux (e.g. wine mywinpgm).
I git cloned the Picaso library and after some fiddling, I was able to get it to compile after pointing it to wine's version of windows.h
Picaso's OpenComm is doing CreateFile [a win32 API call]. So, you'll probably need cygwin. You're opening /dev/ttyUSB0. /dev/* implies cygwin. But, /dev/ttyUSB0 is a Linux-like name. You may need some WinX-style name like "COM:" or whatever. Under the cygwin terminal [which gives you a bash prompt], do ls /dev and see what's available.
You can get cygwin from: http://cygwin.com/ If you have a 64 bit system, be sure to use the 64 bit version of the installer: setup-x86_64.exe It's semi-graphical and will want two directories, one for the "root" FS and one to store packages. On my system, I use C:\cygwin64 and C:\cygwin64_packages--YMMV.
Note that the installer won't install gcc by default. You can [graphically] select which packages to install. You may also need some "devel" packages. They have libraries and .h files that a non-developer wouldn't need. As, docs mention, you can rerun the installer as often as you need. You can add packages that you forgot to specify or even remove ones that you installed that you don't need anymore.
Remember that you'll need to adjust makefile -I and/or -L option appropriately. Also, when building the picaso library, gcc generated a ton of warnings about overflow of a "large integer". The code was doing:
#define control_code -279
unsigned char buf[2];
buf[0] = control_code >> 8;
buf[1] = control_code;
The code is okay, and the warning is correct [because the code is sloppy]. If the code had done:
#define control_code -279
unsigned char buf[2];
buf[0] = (unsigned) control_code >> 8;
buf[1] = (unsigned) control_code;
it probably would have been silent. Use -Wno-overflow in your Makefile to get rid of the warnings rather that edit 50 or so lines
I installed the base package to compile C++ with MinGW Installer GUI and CMake. I created a simple file .c with hello world, and can use cmake . -G"MSYS Makefiles" normally. I added E:\Programmation\MinGW\bin and E:\Programmation\MinGW\msys\1.0\bin to my path.
Here is my CMakeLists.txt:
cmake_minimum_required (VERSION 3.3)
project (Prototype)
set (EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})
file (
GLOB_RECURSE
source_files
src/*
)
add_executable (
my_exe
${source_files}
)
Once the makefile is created however, when I use make I'll get the following error:
/bin/sh:/e/Users/MyName/Documents/GitHub/ProjectName/prototype/c/E:/Programmation/MinGW/msys/1.0/bin/make.exe: No such file or directory
make.exe": *** [all] Error 127
I can compile the file main.c just fine with gcc main.c and the exe it produces works, so the problem is with the make.exe.
If I use it in the msys.bat shell, located in E:\Programmation\MinGW\msys\1.0, it works as it should. So my guess is that the problem is with Powershell and the path. I'm thinking maybe it's because of the way hard drives are designated, since in the error I get it calls my E:\ disk /e/ first then E:/. When I work in msys.bat I have to write it this way: /e/Users/MyName...
This is PEBKAC. The problem is not with make.exe, but rather, in the way you are attempting to misuse it.
How many times must I say this? Using MSYS make.exe, (or indeed any of the MSYS tools), in any environment other that the MSYS shell, which is started by running msys.bat, is definitively unsupported by the MSYS Project maintainers.
Since you say you problem goes away, when you use make.exe as you are supposed to, (in the MSYS shell, invoked by running msys.bat), this is your problem, and your problem alone. It apparently does not work, when you attempt to use it improperly, (i.e. from PowerShell): that's tough luck; when you break free software, by misusing it, you get to keep all the pieces.
Contrary to the accepted answer, it is actually possible to do this using PowerShell:
sh.exe -c "cd ""$pathToMake""; make"
Make sure you sanitise backslashes for the shell before the call above.
$pathToMake = $pathToMake -replace "\\", "/"
Also the MSYS bin has to be in your path, which would typically look like this (your path maybe different):
$env:Path = "C:\GNUstep\msys\1.0\bin;$($env:Path)"
I am looking for a simple way to compile Unix MEX files on a Windows 7 computer.
The MEX files compile smoothly in MATLAB 2014a on Mac OS X 10.9 (using "XCode with Clang" as the compiler). Some of the people that I work with, however, are having trouble compiling them in Windows 7 using the C compiler from the Windows 7.1 SDK.
I understand that I might be able to avoid these errors if I use GCC to compile MEX files in MATLAB. I am wondering if anyone knows how. I am happy to download and edit whatever files are necessary so that I can a) compile MEX files within MATLAB by using the "MEX" command and b) guarantee that "-I" and "-L" instructions will also passed to the MEX compiler.
Note, my issue is very similar to this post from 2+ years ago. That said, I have put up a new post since a) MATLAB/MinGW/MEX have all had significant updates since then (not even sure if MinGW is the easiest way out of this mess); b) there is a 64 bit thing (not sure if it's a problem) and c) the "-I" and "-L" options are important.
Start by downloading MinGW-w64 compiler toolchain. We'll be using the x64 version. Here's the link to the latest binaries as of this moment (GNU GCC 4.9.1).
Extract the 7z archive to some location (preferably without spaces), say C:\MinGW-w64\mingw64.
Add the bin folder to your PATH environment variable, so something like set PATH=C:\MinGW-w64\mingw64\bin;%PATH% but do it system-wide.
Create the following file (feel free to add compiler switches like -std=c++11 if you want C++11 support):
mexopts_mingw64.bat
#echo off
set MATLAB=%MATLAB%
set MW_TARGET_ARCH=win64
set MINGWROOT=C:\MinGW-w64\mingw64
set PATH=%MINGWROOT%\bin;%PATH%
set COMPILER=x86_64-w64-mingw32-g++
set COMPFLAGS=-c -m64 -mwin32 -mdll -Wall -DMATLAB_MEX_FILE
set OPTIMFLAGS=-DNDEBUG -O2
set DEBUGFLAGS=-g
set NAME_OBJECT=-o
set LINKER=x86_64-w64-mingw32-g++
set LIBLOC=%MATLAB%\extern\lib\%MW_TARGET_ARCH%\microsoft
set LINKFLAGS=-shared -L"%LIBLOC%" -L"%MATLAB%\bin\%MW_TARGET_ARCH%"
set LINKFLAGSPOST=-lmx -lmex -lmat
set LINKOPTIMFLAGS=-O2
set LINKDEBUGFLAGS=-g
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
set RC_COMPILER=
set RC_LINKER=
Now we use it to compile a sample MEX-file:
>> mex -f mexopts_mingw64.bat -v -largeArrayDims "C:\Program Files\MATLAB\R2014a\extern\examples\mex\yprime.c"
>> yprime(1,1:4)
ans =
2.0000 8.9685 4.0000 -1.0947
Note: If you are compiling C++ code and you want to distribute the binaries to other people, you might need to also include a couple of DLL files from MinGW which will be dependencies for the compiled MEX-file (stuff like libstdc++). Use Dependency Walker tool to list them all.
I was using Fortran g77 and experienced this problem:
c this program calculates runoff and sediment
1 2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
Also, the compiler can recognized only .for file extension, not .f.
Does anyone know, where is the problem? I downloaded it from http://www.cse.yorku.ca/~roumani/fortran/ftn.htm.
The compiler is not recognizing that statement as a comment. As a comment it should ignore the line but it is trying parse it. Are you sure that the "C" is in the first column?
Why are you using g77? It hasn't been supported for years. gfortran is the current GNU Fortran compiler. It can compile FORTRAN 77, Fortran 90, 95 and portions of 2003 and 2008.
EDIT: Perhaps its wants an upper-case "C".
The page you have linked to states that the f2exe wrapper passes -ffree-form to the compiler:
Compilation Command
The above f2exe command is just a batch file that invokes g77, the "real" compilation command. The command:
g77 -ffree-form prog.for -oprog.exe
directs the compiler to compile the file prog.for and stores the output in the file prog.exe. The -ffree-form switch indicates free-form style (remove it if you are using the old style).
In free-form Fortran the only allowed comment format is that of a line starting with !. As a matter of fact, this is also written on the same page directly under the above text:
Comments
In free-form style, use ! for both full-line and in-line comments. In the old style, use a "C" in column-1.
If you are not using the provided f2exe wrapper, don't pass -ffree-form option when compiling fixed-form FORTRAN 77 code.
I'll assume you want to stick with this compiler.
As noted above, the problems you have come from using the F2EXE batch file, which is not very useful: first it automatically adds ".for" to the file name, so you can't compile ".f" files, and it assumes free-form syntax, which is unusual when programming in Fortran 77 (and if you want Fortran 90, find another compiler, other answers give you links).
Now, suppose you have written a program myprogram.f, and you are in a Windows command line, in the same directory where the program resides (use "cd C:\mydirectory" for example, to change)
You will compile with
g77 myprogram.f
If you use SLATEC, you use
g77 myprogram.f -lslatec
If you want to specify a name for your .exe file (default is a.exe), you write
g77 myprogram.f -o myprogram.exe
There are other useful options
g77 -O2 myprogram.f to optimize (within g77 2.95 limitations)
g77 -Wall myprogram.f to enable all compiler warnings, very useful
to find errors in your code
g77 -c myprogram.f to only compile (you get a .o file), this is
useful to compile functions and subroutines, to
later build a static library (.a file), like
libslatec.a which is given with the compiler
And to build a library, using ar.exe:
ar cru mylib.a myfunc1.o myfnuc2.o ...
Then you can use is with
g77 myprogram.f mylib.a
G77 runs in command line under Windows. You write programs in a text editor.
Notepad++ is fairly good and its free. See http://notepad-plus-plus.org/
If you have problems with compilation, maybe it comes from environment variables, so here are some precisions. You have to tell Windows where to find the G77 compiler (g77.exe).
You can follow instructions on the site where you downloaded it to change Windows' environment variables PATH and LIBRARY_PATH. It needs you install the compiler in the C:\F directory : that is, you will have C:\F\G77\bin, etc.
Slight modification to the instructions on that page :
You should set PATH to C:\F\G77\bin
And LIBRARY_PATH to C:\F\G77\lib;C:\F\SLATEC\lib
This modification to LIBRARY_PATH allows you to compile with SLATEC simply with "-lslatec" as above.
A note about the compiler. It's G77, also know as GNU Fortran 77. An old compiler, integrated with the well known GCC suite until GCC 3.4.6 (we are at GCC 4.7.2 now). And the compiler you downloaded is for version GCC 2.95.
It's a good Fortran 77 compiler, but it's not very well optimized, and of course, you don't get any support for new processor features such as Intel SSE.
Modern Fortran compilers can still understand most if not all of Fortran 77, plus all the newer features of Fortran 90 and newer standards, which are extremely useful.
It may also be interesting to know there is another place to download the same compiler (eccept there is no SLATEC), just in case the page gets destroyed :
http://www.mbr-pwrc.usgs.gov/software/g77.html