Dev C++ compiler reading Window sys variables

[Troy Seman]

I'm working with a basic "Hello World" program...

include <stdio.h>

int main(void)
{
printf("Hello World.");
}

...

I get the following compiler log...

Compiler: Default compiler
Executing g++.exe...
g++.exe "C:\Documents and Settings\supervisor\Desktop\test.cpp" -o "C:\Documents and Settings\supervisor\Desktop\test.exe" -I"C:\Apps\Dev-Cpp\lib\gcc\mingw32\3.4.2\include" -I"C:\Apps\Dev-Cpp\include\c++\3.4.2\backward" -I"C:\Apps\Dev-Cpp\include\c++\3.4.2\mingw32" -I"C:\Apps\Dev-Cpp\include\c++\3.4.2" -I"C:\Apps\Dev-Cpp\include" -L"C:\Apps\Dev-Cpp\lib"
C:/Apps/g95/lib/crt2.o(.text+0x16a):crt1.c: undefined reference to `__cpu_features_init'
collect2: ld returned 1 exit status

Execution terminated

...

The C:/Apps/g95 directory is an install of Fortran. This path should be unknown to Dev C++. This path occurs in the windows environmental variable "LIBRARY_PATH" and is necessary for a command line Fortran Compiler. If I remove this variable and restart Dev C++ the program will compile just fine. If I leave this variable in place, open a command line window and compile the program using g++ or gcc from the Dev C++ install directory, the program will compile just fine.

I've poured over the verious options and settings in Dev C++ but cannot find anything that will direct, or rather undirect Dev C++ from using system variables (Path statements). How do I stop this behavior? Keep in mind that I need these variables in place for other programs.

The workaround would be to start Dev C++ and a fortran command line window with alternate batch files that will set and destroy this LIBRARY_PATH variable on the fly. I'd like to avoid doing this because it's messy and I may have further problems down the road with system variables from other programs so I would like to understand/solve this problem from within Dev C++.

Thank you.

[cpns]

> And yes. The system variable read being hard coded would, in my book, be a bug.

That is not quite what I meant (or said). It was the appending rather than pre-pending of the PATH environment variable that is a bug. The LIBRARY_PATH variable is a GNU toolchain variable and the compiler is designed to use that. When building from the command line it makes things simpler not to have to specify library locations.

That said however, it would not be impossible for Dev-C++ to execute the compiler in its own private environment rather than inheriting the prevailing environment.

Another solution is to remove all these GNU environment variables from your system and specify the path options explicitly in your Fortran builds as Dev-C++ does for C++ builds.

Finally, it occurs that rather than setting a -L option for the crt2.o path, you could explicitly link Dev's version of the file, then the linker would not need to resolve the reference by searching. Just add the object file to the linker options (there's a button in the project options dialog to do just that.

Clifford

[cpns]

Unfortunately Dev-C++ creates its local build environment by appending its path to PATH rather than prepending or replacing it. That is a bug in my opinion. It means that any GNU based toolchain (which your Fortran compiler no doubt is) that appears in the path is encountered before Dev-C++'s MinGW installation.

Manually adding C:\Apps\Dev-Cpp\bin to the PATH environment variable ahead of C:/Apps/g95/ will probably solve the problem for Dev-C++, but may adversely affect your Fortran compiler or any other GNU toolchains. One solution to that is to create a batch file that modifies the path then runs Dev-C++. Modify any Dev-C++ shortcuts you have to run this batch file instead of Dev-C++ directly. The modified environment will be local to that batch execution session.

Alternatively use a different log-in for Dev-C++ development with a different PATH setup.

I would avoid placing your projects in "C:\Documents and Settings\supervisor\Desktop\", apart from the fact that many compiler generated intermediate files will end up littering your desktop, the path contains spaces which is known to cause problems for GNU builds in some circumstances.

Clifford

[cpns]

Sorry, I misread your problem. LIBRARY_PATH is an environment variable common to all GNU compilers, which is why it affects both. There are several others applicable to the GNU Compiler Collection (gcc) or which both belong. http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Environment-Variables.html#Environment-Variables .

It might not have been a problem, but I suspect that one is Cygwin based, and the other MinGW and they are not compatible.

A separate login, or even a separate Virtual Machine may be your best solution, or as you suggest build environment batch files.

My preferred solution would be to use a different non-GNU C++ toolchain. http://www.microsoft.com/express/vc/ I have not even bothered to re-install Dev-C++ after using this.

Clifford

[cpns]

Possibly another solution. -L<path> options take precedence over LIBRARY_PATH, so if you find the path to the version of crt2.o in the Dev-C++ installation that should be used instead, and specify that path in the compiler options library directories list, it may resolve the issue.

Good luck.

Clifford

[Troy Seman]

Thanks Clifford. I saw other posts by you and was hoping you'd be the guy to answer mine. The batch files seem to be working. Dev C++ adds the -L switch when it compiles but this did not help. As for Visual C++ express... What can I say, the instructor likes Dev C++.

And yes. The system variable read being hard coded would, in my book, be a bug.