Using gcc to compile C file

[JRace]

I also use Notepad++ to compile with QB64PE & MinGW using the NppExec plugin.

Here are the lines I use in npes_saved.txt for NppExec.  They assume Notepad++ is in a directory parallel to QB64PE; in my case they are
"c:\prog\npp" & "c:\prog\qb64pe":

Code: (Select All)

::QB64PE compile
cls
npp_save
env_set QBCDIR=$(NPP_DIRECTORY)\..\qb64pe
env_set PATH=$(SYS.path);$(NPP_DIRECTORY)\..\qb64pe
cd "$(CURRENT_DIRECTORY)"
"$(NPP_DIRECTORY)\..\qb64pe\qb64pe.exe" -c -s:exewithsource=true "$(FULL_CURRENT_PATH)"
env_unset PATH
env_unset QBCDIR

::QB64PE MinGW compile
cls
npp_save
env_set PATH=C:\prog\qb64pe\internal\c\c_compiler\bin;%PATH%
"C:\prog\qb64pe\internal\c\c_compiler\bin\gcc.exe" "$(FULL_CURRENT_PATH)" -Wall -m32 -static-libgcc -static-libstdc++ -fomit-frame-pointer -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe" -static -Os -s -lwsock32
env_unset PATH

NppExec can use absolute paths or paths relative to your Notepad++ folder.  The example above uses both types of paths.

[bplus]

+1 thanks @jrace that might be handy with book i am reading (referring to bat file ends page 1)

[JRace]

Lemme know if it gives you any problems.

It's a Frankenstein's monster, pieced together from the suite of batch files that I normally use, but it seems to be friendly.

[Kernelpanic]

-Os -s -Wall -static-libgcc -static-libstdc++ -static -fomit-frame-pointer -luser32 -lgdi32 -lshell32

@JRace, I looked at the compiler options in your bat file and found them a bit confusing. The description of the individual options for GCC can be found here: 
GCC - Compiler Options

Regarding -fomit-frame-pointer: "Omit the frame pointer in functions that do not require one. This eliminates the instructions for saving, setting up, and restoring the frame pointer."
https://gcc.gnu.org/onlinedocs/gcc/Optim...me-pointer

Optimization: "Optimize. Compile optimization requires a little more time and a lot more memory for a large function.
With -O, the compiler tries to reduce code size and execution time without performing optimizations that take a lot of compile time."

-Wall makes sense because the option displays warnings if the source code was compiled but contains imperfections.

In my opinion, something is wrong there. It seems to me that some options interfere with each other, and I can't find this one in the description: -luser32 -lgdi32 -lshell32.

I doubt that it makes sense to compile every file with all the specified compiler options.

[JRace]

Yeah, I could have shortened that line a bit.
Feel free to edit that line in the batch file to suit your needs.

Anyway:

• -Wall: forces GCC to issue warnings for things that it would normally ignore, such as unused variables.
  
• -Os: optimize for smaller size.  Gives most of the speed benefits of -O2, but makes smaller EXEs.
  
• -s:  Remove all symbol table and relocation information from the executable.  Makes smaller executable.
  
• -fomit-frame-pointer: can give a tiny speed boost and make the EXE a tiny bit smaller.
  
• -static: This tells the linker to statically link the program (build needed functions from the Standard library into the EXE) instead of requiring external library DLLs.  I hate when I run a program and Windows tells me that I need certain .DLLs.  (Note that static linking will cause your EXE file to be bigger)
  
• -static-libgcc & -static-libstdc++: More static linking.  These two are not needed if -static is used, but I despise DLL dependencies.
  
• -luser32 , -lgdi32 , -lshell32: These tell the linker to link against user32.dll, gdi.dll, and shell.dll.  Those are all standard Windows DLLs which we don't normally need to specify, but I needed them at some point, so I just left them in there.
  

A person really doesn't need any of these.
I suppose my personal option list would be -Wall -Os -static, but your tastes may be different.
I recommend -Wall to help create programs with fewer bugs.
Any optimization setting is up to the creator.  I've always been fond of -Os.
If you don't use -static linking, then you may need to copy some DLLs from the GCC bin\ folder.

[Kernelpanic]

@JRace, the problem ultimately lies in the fact that you absolutely want to use QB64's GCC. (The program for deleting it is yours, right? And that's well!)

Bat files cannot be used meaningfully if they are not in the path. I've known this since 1995, when I was still programming with QuickC, and more (I have all QuickC versions with manual 1.0, 2.0, 2.5 the last one). Back then you had to write this into the autoexec.bat for it to work. The compiler options for the Quickc compiler were also in there. So that you can access it from any directory.

The most practical use is to include the GCC in the path, and if you want to make it easier you can create a bat file with: -o -Wall. This should apply to the vast majority of all files. For the rest, just enter it directly.

That was my autoexec.bat file. The instructions for the QuickC compiler were set so that I only had to call it on the command line with a bat file (the reason for this was that many programs were 1/3 smaller than when compiled in the QuickC IDE became.):

Code: (Select All)

echo off
cls
qcl %1.c

The autoexec.bat

Code: (Select All)

@ECHO OFF

PATH C:\WINDOWS;C:\WINDOWS\COMMAND;G:\;C:\DOS;C:\SDK-JAVA20\BIN;C:\;E:\MSVC\BIN;F:\;F:\CURRE!;F:\QC25\BIN;F:\QB4;F:\COBOL;F:\WP51;F:\DBASE;F:\MASM51



VERIFY ON

PROMPT $e[s$e[1;67H$e[1;32m$e[2;67H$t$h$h$h$e[u$e[1;31;40m$p$g$e[1;33;44m



Rem ---------------------- MTM ATAPI CD-ROM ----------------------

Rem - By Windows Setup - LH /L:1,36224 C:\WINDOWS\COMMAND\MSCDEX.EXE /D:MTMIDE01 /M:10

Rem ---------------------- MTM ATAPI CD-ROM ----------------------



LH /L:1,7792 C:\DOS\NLSFUNC  C:\DOS\COUNTRY.SYS

C:\DOS\MODE CON CP PREP=((850)C:\DOS\EGA.CPI)

C:\DOS\MODE LPT1 CP PREP=((850)C:\DOS\5202.CPI)



CHCP 850

LH /L:1,17184 C:\DOS\KEYB GR ,, C:\DOS\KEYBOARD.SYS

C:\DOS\mouse.COM /Y



Rem . . .



SET LIB=F:\QC25\LIB;F:\QB4

SET INCLUDE=F:\QC25\INCLUDE

SET LINK=F:\QC25\BIN\QLINK /CO /NOI /LI

Rem INC /PADC /PADD

SET CL=/FPi87 /AM /G2 /Bd /Zi /Zd /Ox

SET MASM=/C /V /Z /ZI



SET TMP=C:\TEMP

SET TEMP=C:\TEMP



CLS

[JRace]

AUTOEXEC.BAT is good for permanent, system-wide settings, but for compilation we only need a short-term, temporary solution.

The batch file I posted must be run from the QB64PE directory or from the MinGW directory.  This fact could be changed with a small modification to put QB64PE's location into the batch file.  My concern was to make the batch file "just work" without  too much customization.

The batch file DOES set the path before running the compiler, even though setting the path for GCC is NOT mandatory.  The batch file determines where GCC.EXE is located and could call the compiler directly if we wanted it to.  GCC knows where its own files are located relative to itself, so GCC does not actually need the PATH.

The PATH and environment variables can be set at ANY time before running the compiler.  That setting does not need to be permanent or system-wide.

The PATH can be set "on the fly" from the command prompt, either by typing or by using a batch file such as this one, which sets the PATH variable then opens a command prompt:

Code: (Select All)

@echo off
REM Must be run from the QB64PE directory.
SETLOCAL ENABLEEXTENSIONS

if not "%MGWDIR%"=="" goto bermuda
if not exist "%~dp0internal\c\c_compiler\" echo MinGW subdirectory not found. & pause & goto bed
set MGWDIR=%~dp0internal\c\c_compiler
set PATH=%MGWDIR%\bin;%PATH%

:bermuda
start "%ComSpec%"

:bed

All of the changes made by this batch file will be forgotten by Windows when the command prompt is closed and this file terminates.

I currently have 18 compilers and interpreters ready for immediate use, with many more available if needed.  Imagine how long and confusing my PATH would be if I added ALL of those directories to it.



(I guess I'm a language hoarder.)

Each of these compilers has batch files which set the PATH and other environment variables only when needed.  Then, when the compiler is finished and the batch file ends, Windows forgets all of those changes.

Many years ago I created similar batch files for Quick C, Turbo C, Small C, DeSmet C, and any other compiler that I found myself using.

Here is a batch file I wrote to compile programs using Quick C:

Code: (Select All)

@echo off
if not "%QUICKC%"=="" goto bermuda
set QUICKC=c:\prog\qc
set OLDPATH=%PATH%
set PATH=c:\prog\qc\bin;%PATH%
set LIB=c:\prog\qc\lib
set INCLUDE=c:\prog\qc\include
:bermuda
qcl.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
set %PATH%=OLDPATH
set OLDPATH=

(AUTOEXEC.BAT not needed.  This batch script uses hard-coded full paths to QC, so it can be run from anywhere.  Before this script terminates it resets the path back to its original value, since the DOS command prompt never closes and path changes are not forgotten until reboot.)

When I started using Windows I was so weary of creating so many batch files that I wrote a program generator that can create many batch files from one .INI file.

It's all quite clean, simple, and very functional.

[Kernelpanic]

@JRace - the autoexec.bat is from 1995! From Windows XP onwards it was no longer necessary. It was still there, but it was empty because the system no longer took it into account.

The autoexec.bat and the config.sys were only relevant for the DOS-based versions of Windows, i.e. until Windows Me.

[JRace]

@JRace - the autoexec.bat is from 1995! From Windows XP onwards it was no longer necessary. It was still there, but it was empty because the system no longer took it into account.
The autoexec.bat and the config.sys were only relevant for the DOS-based versions of Windows, i.e. until Windows Me.

Which is why my original post never mentioned AUTOEXEC.BAT.  YOU mentioned it in your previous post.  I guess I misunderstood the intent of that post.

I think I misread the intent of that post.  I thought maybe you did not understand how my batch script worked, so I went on to explain how the batch file worked, and that a permanent PATH setting is not needed.

I then listed a batch script from my own Quick C installation which demonstrated that permanent PATH settings are not necessary for compilers, even in DOS.

If a person has just one compiler or is using one particular compiler all day, every day, then a permanent PATH setting can be justified, but my compiler batch scripts follow a "set it, use it, forget it" philosophy that has worked very well for years.


(EDIT: I've tweaked the batch script in my first post and added a few more comments.  Not a @TerryRitchie level of comments, but a few which may be useful.)

[TerryRitchie]

Not a @TerryRitchie level of comments, but a few which may be useful.)

LOL, yeah, my code gets wordy, but when I revisit my code later I'm sure glad I took the time to do it. Plus, I need to comment code very well for the tutorial so I must stay in the habit.