Following the instructions on http://iitdu.forumsmotion.com/t108-gcc-compiler-in-notepad
However, upon execution of NPPExec with the code provided (below), ld.exe displays a warning detailing that linintl-8.dll is missing.
// The script code, C source code compiling with GNU CC (GCC) in notepad++ (by "NppExec" plug-in) and compressing with UPX...
//
// Enable? "//" signs remove in code line.
// Sample: C:\Program Files\CodeBlocks\MinGW\bin\gcc.exe "$(FULL_CURRENT_PATH)" -o $(NAME_PART)
YOUR_GCC\BIN\_PATH_HERE\gcc.exe "$(FULL_CURRENT_PATH)" -o $(NAME_PART)
// UPX Compress (with "--best, --ultra-brute" options)
// Enable? "//" signs remove in code line.
// Sample: C:\WINDOWS\system32\upx.exe --best --ultra-brute $(NAME_PART).exe
YOUR_UPX_PATH_HERE\upx.exe --best --ultra-brute $(NAME_PART).exe
Yet, I can see linintl-8.dll sitting in the bin directory of mingw.
Does anybody have any idea how this issue can be resolved, or alternatively an entirely different method to successfully compile C in notepad++ ?
I'm no Windows expert, but I know that dlls should go somewhere in C:/System or C:/System32 for Windows 7 you should check this question:
How do I register a DLL file on Windows 7 64-bit?
Related
So I am making a desktop application using C and the Win32 API. I am also using CMake/Make in conjunction with MinGW. Everything went smoothly until I wanted to add an .rc file to the executable. From my understanding you write an .rc file which is then compiled to a .res file, then presumably you are supposed to embed it in the executable. Here's the problem however, when I attempt to compile the .rc file with the GNU utility windres it fails to compile. I always get the following error messages:
C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\windres.exe: can't open file `page:': Invalid argument
C:\Code\C\test\resources.rc:4: fatal error: when writing output to : No such file or directory
4 | IDI_TEST_ICON ICON "test.ico"
|
compilation terminated.
C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\windres.exe: preprocessing failed.
This occurs with every .rc file I've tried, for completeness however, here is the current test file I am trying to compile:
#include <windows.h>
#include "resource.h"
IDI_TEST_ICON ICON "test.ico"
And the resource.h file:
#define IDI_TEST_ICON 101
So the final question is the following: Why doesn't windres compile the .rc file successfully? And what can I do about in the context of using MinGW?
Edit 1:
Worth noting is that I also converted the .rc file to ANSI format since windres is notorious for yielding peculiar errors when formatted in UTF-8. Yet, the same errors occur.
windres actually generates an object file (in COFF format)
So you should run the command like this:
windres resource.rc -o resource.o
When I check the format of the generated file like this:
file resource.o
I get the following result:
resource.o: Intel amd64 COFF object file, no line number info, not stripped, 1 section, symbol offset=0x3c4c, 1 symbols
So you just need to include the generated .o file in the link step to include the resource.
For example when you run the following command you will get an .exe that won't run, but it will show the icon in Explorer:
gcc -shared -o resource.exe resource.o
After a lot of digging in old forum threads I managed to find a "solution" that works. However I still find it peculiar that this solves the problem. I followed Brecht Sanders advise and downloaded a standalone build from winlibs.com. Even this didn't solve the problem which led me to investigate possible RC_COMPILER_FLAGS which ultimately led me to the --use-temp-file flag.
This flag acts as an alternate approach to compile .rc files since it excludes the use of popen (or the equivalent of it in Windows). According to the documentation this flag should be used if the implemenation of popen is buggy on the host. What is interesting here is that the documentation states that this is known to happen on certain non-english versions of Windows. In my case I am using the Swedish language version of Windows which might explain why this is occuring.
Thus the final solution turns out to be:
windres -i resource.rc -o resource.o --use-temp-file
Which ultimately yields an object file which can then be included in the add_executable call in CMake.
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'm trying to compile a C program with a icon attached.
I'm following this instructions: How do I add an icon to a mingw-gcc compiled executable?
Both Evan's and Steven's replies.
I'm getting this error 4x:
ico.rc:1: unrecognized escape sequence
when I run:
windres ico.rc -O coff -o ico.res
The working dir is where the executable, source file and 'icon.ico' files are. The icon is just an png converted with
ffmpeg -i icon.png icon.ico
The '.rc' file content is:
id ICON ico.ico
My machine is a Windows 10 32-bits with MINGW, without Microsoft Visual Studio.
How can I compile my program with an icon?
I was searching for the same problem, and found the solution in another site (https://dev-cpp-users.narkive.com/AEWfAsk2/dev-c-problem-with-resource-files), so here I am to share it:
doesn't work because you need to use forward slash (/) as
directory seperator - backslash does not work.
Changing the slashes inside the .rc file was enough for it to work (in cause you also need slashes in the windres command, it can be ). Also, the path inside the .rc file doesn't like accents (eg: áàé).
Edit: I just noticed that the How do I add an icon to a mingw-gcc compiled executable? post says in the example
"path/to/my.ico"
not
"path\to\my.ico"
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
I have a problem with compiling and running C codes in notepad++.
I am using the nppexec plugin and wrote the following in the script section after pressing F6:
C:\MinGW\bin\gcc.exe -g "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
$(CURRENT_DIRECTORY)\$(NAME_PART).exe
After pressing OK, I get the following on the console:
C:\MinGW\bin\gcc.exe -g "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.C" -o "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe"
Process started >>>
<<< Process finished. (Exit code 0)
D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe
Process started >>>
Here, substitution.c is my program to be run. The problem is that the gcc part is working fine but I am not able to execute the program from here as there is no response.
As you see, it just says process started and after that nothing. No response to a key being pressed, it just accepts everything like a text editor.
If I go to the working directory and execute the program from there (double clicking the exe file) then it seems to run perfectly fine. The problem seems to be in my script or the plugin.
Please, can anyone find out what is wrong with my compiling and running script?
In addition to #paxdiablo 's answer, you may also find useful the following NppExec script for single file projects:
npp_save
cd "$(CURRENT_DIRECTORY)"
cmd /c del "$(NAME_PART)".o "$(NAME_PART)".exe *.o
C:\MinGW\bin\gcc.exe -g3 -std=c89 -pedantic -Wall -Wextra -Wno-nonnull "$(NAME_PART)".c -o "$(NAME_PART)".exe
npp_run "$(NAME_PART)".exe
The 1st line saves the document that is currently active inside notepad++.
The 2nd line ensures your current directory is the one of the active document. This let you refraining from using the "$(CURRENT_DIRECTORY)" variable in the rest of the lines.
The 3rd line removes any executables and object-file leftovers from previous successful compilations. Removing the last executable is a nice idea, because if you don't then the last line will cause your .exe produced by the last compilation to be run anyway, even if your current compilation fails. A failed compilation does not produce an .exe, so normally you don't want NppExec to run the previous .exe. Removing the previously produced object-file is optional, but it does ensure that it will not affect fresh compilations (it makes more sense in multi-file projects, as an alternative to the touch command-line tool).
The 4th line compiles the active document. Feel free to modify gcc's options according to your needs. If you add C:\MinGW\bin into the Windows PATH environment variable, and assuming you are using only one gcc installation on your system, then you can skip the absolute path, and write just gcc instead.
The last line executes the produced executable. The npp_run command tells NppExec to launch a new command-prompt window, and run your program in it (unless it is a WIN32 GUI program). I personally find it more convenient compared to the NppExec console embed in notepad++. It looks more natural and it also avoids some I/O redirection problems of the NppExec console.
However, if your program is a console app that does not interact with the user say via a loop, then this approach will cause the launched command-prompt window to close immediately after your program terminates, not giving you the chance to inspect its output. In that case you should have you program waiting for a key to be pressed by the user just before its termination. A quick-and-dirty way is to put a system("pause"); right before your main() function's return and/or exit() statements (it is much better though to write a simple cross-platform function or macro for this).
You may experiment with the above script by typing it in F6's <temporary script> and save it permanently for general use when you are happy with its behavior.
On a side note, you may also find it useful to have a look at this post, where I'm trying to explain how to setup NppExec so it jumps to the appropriate line in the source code, by double-clicking on any error gcc spits in the NppExec console during compilation.