Setting up GNU G77

[gsal]

Hi:

I am new to Code::Blocks and when looking for an IDE/Compiler combination in Windows to port my UNIX programs, I found out about C::B and the possibility of making it use GNU GCC/G77.

So I installed C::B standalone version.  Then I installed MinGW.  Launched C::B; it found mingw compilers and setup directory path appropriately. Nevertheless, when I attempt to compiled a simple program I get the "invalid # directive error" for the very first line of the program which is "#include <stdio.h>".

It's a little disappointing that the program did not work right out of the box.  Any suggestions?



...but after following the instruction in the wiki, I get the following error message when attempting to build a simple program.

g77.exe - Application Error
The instruction at "0x0040b235" referenced memory at "0x00000000". The memory could not be "read".

Oh, well, I just did another test and the same thing happens when trying to build a C program...

[Michael]

Hello,

If you use RC2, please give a try to the latest nightly build or build C::B from the SVN sources.

If you would like to use C++ and Fortran, you can have a look at this C::B wik article and topic.

Michael

[gsal]

First of all, thanks for the reply.

I just noticed that my posting did not come out too good...sorry, I should have done a preview, first.

What happened is that initially I was having the application error mentioned at the bottom of my first posting...but then I re-installed and just ended up with what I said on the top of my posting. 

Anyway, initially, I did follow the suggested article in the wiki for installing G77 but did not work.  Tha'ts when I proceeded to re-installed C::B, without modification for G77, to start with and just first try a C program with C::B right out of the box..."baby steps...baby steps!".

Overnight, it ocurred to me that the problem hinted by the error message about invalid directive in the very first line of the program may have something to do with the line termination character...I am working on Windows and wondered if C::B, as default, comes with the line termination for unix...I will check for that when I get to the office in a couple of hours.

[Michael]

First of all, thanks for the reply.

You are welcome .

I just noticed that my posting did not come out too good...sorry, I should have done a preview, first.

What happened is that initially I was having the application error mentioned at the bottom of my first posting...but then I re-installed and just ended up with what I said on the top of my posting. 

Anyway, initially, I did follow the suggested article in the wiki for installing G77 but did not work.  Tha'ts when I proceeded to re-installed C::B, without modification for G77, to start with and just first try a C program with C::B right out of the box..."baby steps...baby steps!".

May be actual modifications of C::B have made the installation tutorial not correct. May be MortenMacFly can say something about. 

Overnight, it ocurred to me that the problem hinted by the error message about invalid directive in the very first line of the program may have something to do with the line termination character...I am working on Windows and wondered if C::B, as default, comes with the line termination for unix...I will check for that when I get to the office in a couple of hours.

About line termination, you can modify it in Settings-->Editor (End-of-line options).

Michael

[MortenMacFly]

First of all the good news: In my memory G77 did work with RC2 but it certainly works with the current SVN version (I use it nearly every day). But I have a couple of questions to clarify:

1.) If the G77 executable fails this doesn't look good and is very strange. I belive this is not an error of C::B. Did you first of all try to compile a "Hello World" Fortran application not using C::B?
2.) If compiling works using MinGW only (you may want to download the packages seperately in another folder and/or use MSYS) you can do the next step. But here I wonder: You said you compiled a C application the second time. Why does the G77 compiler crash than?
3.) Please keep in mind that the compiler versions must fit. C::B ships with MinGW version 3.4.4 (without G77). If you download the current version of G77 this is version 3.4.5 as of now. Did you keep that in mind? What versions are you using?
4.) I agree with what the others say: Another solution would be to uninstall C::B RC2, remove all settings (in registry and in the user-application folder). Then you install a current SVN (from the nigtly builds) and the current version of MinGW - the packages required are at least: binutils, mingw-runtime, w32api, make, gcc-core, gcc, g++, g77 and maybe mingw-utils. Then follow the steps again as on the WiKi. I do it the very same for every new installation (to remember this is why I wrote the WiKi.. ;-)).
5.) Verify your PATH settings are correctly. Please keep in mind that the PATH variable (and maybe others) from the OS is taken into account on compiler level. So if you setup the PATH to point to another folder with libs/headers this may result in conflicts.

Maybe this helps a little... Good luck!

Morten.

[gsal]

O.k. thanks for all the hints.

First, the end of line character did not solve the problem...so I decided to start all over again. 

I did follow the wiki and downloaded all the necessary MinGW and GCC files as listed from the gcc 3.4.4 manual install section. I also downloaded msys (1.0.10).

Now, forget about C::B for the moment...I can't even compile a 1-line C program.

Initially, in the msys bash terminal, I got the error : "gcc installation problem, cannot exec 'cc1': invalid argument.

Then, I don't remember exactly what I did first and when the error message changed but I setup the environment variable exec prefix as follows:

    GCC_EXEC_PREFIX=c:\programstoo\mingw\libexec

and also added  c:\programstoo\mingw\libexec\gcc\mingw32\3.4.4  to PATH ...  since cc1 is somewhere down there.

After doing that, the error message in msys became
    $gcc try.c
    ld: crtbegin.o: No such file: No such file or directory

The error in a DOS window still is the "cannot exec cc1" error, though.

A google search on crtbegin and cc1 reveals problems with these files 3 or 4 years ago, I thought things would have been solve by now...or am I missing something?

The other two environment variables are
C_INCLUDE_PATH=c:\programstoo\mingw\include
CPP_INCLUDE_PATH=c:\programstoo\mingw\include\c++;c:\programstoo\mingw\include

While I realize that I should probably take this matter to a mingw forum, any help from any of you (as mingw users) would be appreciated.

Thanks,

Germán

[MortenMacFly]

[...] environment variables are
C_INCLUDE_PATH=c:\programstoo\mingw\include
CPP_INCLUDE_PATH=c:\programstoo\mingw\include\c++;c:\programstoo\mingw\include
[...]

I wonder: I don't really need to setup any variables to compile a hello world program. The only thing I need to do is to open a command prompt within the "bin" folder of the MinGW installation (the one that contains gcc.exe, g++.exe...). I don't even need MSYS. But if you want to use MSYS (to have a bash) please make sure that there is an entry in the [MSYS_FOLDER]\etc\fstab file that "mounts" the MinGW folder. The entry in my case is: E:/Devel/MinGW /mingw (note the space before the mount point "/mingw").
Morten.

[gsal]

oh, maaaaan!.

Well, no matter what combination I tried...bundled mingw, separate packages, verions 3.4.4 or version 3.4.2...the error was always the same.  At the end, the solution was to have a rather complete set of environment variables pointing everywhere
LIBRARY_PATH=c:\programsToo\MinGW\lib;
                     c:\programsToo\MinGW\lib\gcc\mingw32\3.4.4;
                     c:\programsToo\MinGW\lib\debug

C_INCLUDE_PATH=C:\ProgramsToo\MinGW\include;
                         C:\ProgramsToo\MinGW\lib\gcc\mingw32\3.4.4\include

CPP_INCLUDE_PATH=c:\ProgramsToo\MinGW\include\c++;
                            c:\ProgramsToo\MinGW\include

GCC_EXEC_PREFIX=c:\programsToo\MinGW\libexec

But, thinking of what you said about working just from the bin subdirectory and no environment variables, I want ahead and deleted them all, and guess what...things worked just fine too!!!   hhhhggggg!!!!! ...  from the DOS prompt and from within C::B.

And here I was thinking how smart I was being by setting up environment variables!

Thanks for nothing...just kiding.  Thanks a lot for your patience. 

Hopefully next time I would have a less stupid problem.

Germán

[gsal]

So, where was I?...Oh, yes...I either need no environment variables at all or I need very complete for GCC to work...so, I went for having non as recommended above.

Now, here is my current situation:

 - I am able to compile a C program from the command line (DOS prompt).
 - I am able to compile a C program from within C::B
 - I am able to compile a FORTRAN program from the command line.
 - I am NOT able to compile a FORTRAN program from within C::B. Here is the Build Log:

Project   : Console application
Compiler  : GNU G77 Compiler (called directly)
Directory : C:\Data\salazag\sid\methods\fortran-test\
--------------------------------------------------------------------------------
Switching to target: default
g77.exe    -LC:\ProgramsToo\MinGW\lib -o C:\Data\salazag\sid\methods\fortran-test\f95-test.exe .objs\test.o      -lg2c   
C:\ProgramsToo\MinGW\lib/libmingw32.a(main.o):main.c:(.text+0x106): undefined reference to `WinMain@16'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

Any ideas as to what could the problem be?

gsal

 

[TDragon]

Is the command line Code::Blocks is using (g77.exe    -LC:\ProgramsToo\MinGW\lib -o C:\Data\salazag\sid\methods\fortran-test\f95-test.exe .objs\test.o      -lg2c) the same as the one you use from the command prompt? If you copy and paste it to the command prompt does it work?

"Undefined reference to WinMain" generally means that the linker is expecting a WinMain (Win32 entry point) function, rather than the standard main function, and didn't find one.

[gsal]

Well, I was just trying g77 from the command line and it worked...but when I tried the same entire command as put together by C::B, then I get the same error message from the command line as well.

Idea 1.- Make C::B put together a command as simple as possible, i.e., g77, by editing Compiler settings:
  - Remove library path under Directories
  - Remove -lg2c (that's all I had) Lunder Linker options
=> IT WORKS

Idea 2.- Don't quite understand your explanation about Win32 entry point, but with that hint and the reference to -lstdc++ in the Wiki (even though I don't think I have a mixed project) and went ahead and added -lstdc++ under Linker Options along with -lg2c
=> IT WORKS, as well.

So, I am good shape now, even though I don't quite understand ... maybe -lg2c is bringing some c/c++  code into the picture and hence my project becomes mixed.

Thanks and do you have any additional comments to further explain what is happening? If not that's o.k.  Thanks, again.

gsal

[TDragon]

Well, I'm not at all familiar with the way G77 works, but my only guess would have been that libg2c requires Win32 functionality and thus was looking for a nonexistent WinMain. Since Win32 doesn't imply C++, I have no idea why including libstdc++ fixed the problem.