How to set path to `gfortran` in Eclipse? - eclipse

A colleague got a new mac, and he codes with Eclipse and gfortran. And Makefiles. But now he cannot build.
I figured that Eclipse does not use the same PATH as shell, so while Eclipse is happy to build with a makefile, it cannot find gfortran. (The Makefile works fine when ran form the mac terminal.)
Eclipse can build, if I put the full path in the Makefile (FC=/usr/local/bin/gfortran). But this is extra nuisance when other people use Ubuntu where gfortran has a different path.
Question: How/where to configure Eclipse (Juno) so that it can find gfortran? (I could not find, I tried.)

Why not just use Photran. It is based on Eclipse and is set up for Fortran.

Related

Configuring Eclipse for using with MSYS2

My I use Eclipse Mars and MSYS2. Eclipse does not recognize my MSYS2 installation. It contains Mingw-w64 for 32 bit compilation. Things I have found on the Internet did not work. What should I do?
Well, a bit late to the party, but it looks like there is nothing special about MSYS2: the usual procedure of setting up Eclipse to work with MinGW-w64 installation worked for me just fine.
The main issue is that as described in Eclipse CDT FAQ to detect MinGW toolchain CDT tries to find mingw32-gcc.exe in PATH, while MinGW-w64 have only gcc and i686-w64-mingw32-gcc.exe in its bin directory, so just adding MinGW-w64 bin directory to PATH won't work:
Despite having g++.exe or gcc.exe on your PATH and having defined
MINGW_HOME, you may still get a “Toolchain "MinGW GCC" is not
detected” message (CDT 8.4 on Luna 4.4.0). Make sure that a file
called "mingw32-gcc.exe" exists in MINGW_HOME\bin.
As it mentioned further in Eclipse CDT FAQ, the easy fix would be to copy i686-w64-mingw32-gcc.exe to mingw32-gcc.exe:
If it doesn't exist
(which happens with MinGW-W64), copy a -gcc.exe file (e.g.
i686-w64-mingw32-gcc.exe) to mingw32-gcc.exe. If the dreaded message
still lingers around, reboot your system (don't just logout and
login).
After you did the copying described above, you can add MinGW-w64 bin directory to PATH and Eclipse will recognize the MinGW-w64 installation as MinGW toolchain. Since I don't like idea of polluting neither system nor user environment variables in Windows settings, I usually write a short batch file which adds MinGW-w64 bin directory to PATH and then starts Eclipse for me:
SET PATH=c:\msys32\mingw32\bin;%PATH%
START c:\eclipse\eclipse.exe
Even more later to the party - for me worked this solution: Right click project -> Properties -> C/C++ Build -> Environment: set environment variable MINGW_HOME to C:/.../msys64/mingw64 click OK, and rest is automatically done by eclipse

Eclipse can't find MinGW. Why?

I installed both correctly, but it doesn't matter if I set up the path to compiler correctly or not because it can't find gcc and g++. I checked it with explorer, they were at the correct location. I tried everything I could, even I ran Eclipse in backwards compatibility mode and as an administrator.
EDIT: I'll using Visual Studio 2012 for a while if Eclipse can't be at least as user friendly to having find a solution to the problem under one hour via web.
Download this , chose the desired compilers (gcc and g++) . Make sure you have the value C:\mingw64 in PATH variable under environment variables .
I had to reload my workspace in order to get Eclipse to recognize that.
Also, I had updated the Path variable.
Please follow the same in your case.
I couldn't make the Eclipse (LUNA) to find MinGW on my computer (there were no MinGW available in Preferences>C/C++/New C/C++ Project Wizard) even after I have specified PATH as "C:\MinGW\bin" in Preferences>C/C++/Build>Environment, so what I did afterwards was:
Create a simple "Hello world" C project without specifying any toolchains
(at this step I tried to Build All, and it failed)
Go to Project>Properties, suprisingly, here I could see MinGW GCC as an available choice for Current toolchain. Select it.
Now I could build and run the project
Hopefully, it helps!

Ant "JAVA_HOME does not point to the JDK" - but it does

I cannot run my Ant build.xml since I updated to java 1.7.0_52 (or there about). I have been running it for years through Eclipse locally on my Windows 7 laptop - but with this latest jave jdk update somethings different (?).
BUILD FAILED
C:\workspace\WaterAspectsModel3\build.xml:329: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "D:\Morten\Java\jdk1.7.0_52"
This is my jdk! So JAVA_HOME is pointing to a jdk (as is also clear from the error message). I have my JAVA_HOME with bin folder in my path as always. I've configured Eclipse - external tools configuration - with a JRE pointing to the same D:\Morten\Java\jdk1.7.0_52 (through "Separate JRE" setting). And I've tried a number of other configurations - all without luck.
I've been reading the tonnes of answers on lists here and other places and think I've tried all suggestions. Most seem to be cases where JAVA_HOME actually points to a jre and just needs to be corrected to jdk or there's a ";" in the path or something like that. None of these seem to apply in my case.
Any suggestions?
I was having the same message when running ANT through Eclipse.
What worked for me:
In Eclipse, access the menu: "Window -> Preferences";
Access "Ant -> Runtime", at the tree;
Access the Classpath tab;
Expand the "Global Entries" item;
Inside Global Entries, the path to tools.jar was wrong. It was pointing to an older version of Java;
I removed the wrong entry and added the correct one with "Add External Jars" button. It worked.
The solution
"Had to copy C:\Program Files\Java\jdk1.6.0_10\lib\tools.jar to C:\Program Files\Java\jre6\lib\ext" from here was great helpful and worked for me.
The real message is that Ant can't find com.sun.tools.javac.Main.
Which, together with the fact that the latest "Sun" (Oracle) JDK is 1.7.0_13 (or maybe _14, but definitely not the "_52" that your install dir indicates), makes me think that you're not using a distribution that Ant recognizes. You can verify this by running jar tvf $JAVA_HOME/lib/tools.jar, and looking for that class.
The Ant Manual talks about ways to work with different compilers. Since I've only used "Sun" compilers, I'm afraid that I can't give you any pointers.
Edit: you could also try setting fork="yes" in your build file. This should run the compiler executable rather than trying to invoke the compiler class.
Try adding JAVA_HOME\bin to your env PATH .
Add JAVA_HOME to Eclipse-Preferences-Java-Build Path-Classpath Variables.
Sorry for the unearthing,
I had the same problem, my solution doesn't need any modification in environment variables, and works for a recent JDK where the tools.jar can't be found.
Just go in the small down-arrow next to the ant run button
Then click "Configure external tools"
Then in JRE tab
Select a JDK installed on your computer, not a JRE, no problems if the selected JDK is not the same JDK/JRE as in your project.
It should be work now.

Eclipse CDT not launching executable

I've been using MinGW, no real problems until Eclipse decides it doesn't want to run the executables any more. The run config is still the same, the project builds 100% fine, and I can run the built executable from command line/GUI. The console in Eclipse is empty, save for on the top bar followed by the executable name and time/date.
Just made a hello world project from the menu, same thing happens to it.
I just had the same error, and here is what I did:
Proper binary parser must be selected so Eclipse can recognize the executable: Select the project, then right click.
Project->Properties->C/C++ Build->Settings->Binary Parsers, PE Windows Parser (or you can select Cygwin if you use that compiler, on Linux I use Elf parser.).
That worked for me at least for Cross compiler (both on Windows 7 and Ubuntu 12.04)

Compiling FFMPEG on Windows using Wascana

Has anyone ever tried, or had any success at getting Wascana (Eclipse CDT + MinGW for Windows) to compile FFMPEG under Windows. Apparently it is possible, there is even a tutorial at Craig Shaw's website but I have not been able to make it work.
I run ./configure on the FFMPEG source code then create a new project in Eclipse and point it at the source but it doesn't recognise it as a Makefile project. I think I need to create a builder which works with MinGW but my feeble attempts so far have been unsuccessful.
Hey, I can answer my own question! After a lot of fiddling around, I have come up with the procedure:
NOTE: This is for Wascana 0.9.3 and a Sep 2008 SVN version of FFMPEG.
Prepare Environment
After installing Wascana, you'll need to update various MinGW and MSYS packages. Download and unpack the following (you can download them from the MinGW website):
MSYS packages:
bash-3.1
coreutils-5.97
m4-1.4.7
make-3.81
MinGW packages:
w32api-3.12
MinGW Runtime 3.15
Build
Unpack the FFMPEG source code and configure like so (do not compile it yet):
./configure --enable-memalign-hack --disable-shared --enable-static --disable-mmx --disable-mmx2 --disable-optimizations --disable-stripping
Launch Wascana/Eclipse and create a new C project.
Do not select "Hello World" project, just select a Makefile project and select the MinGW toolchain.
Set the project path to wherever your FFMPEG source code is.
Click finish and the source should build itself!
Install
Right click the project and select Make Targets > Create.
In the dialog, set both the Make Target and Target name to "install".
Run the target you just created. This will install the FFMPEG libraries.
Execute and Debug
Open the Debug Dialog
Right-click on "C/C++ Local Application" and choose "New"
Fill in the project name and select the EXE you want to run (in my case, ffplay_g.exe)
Go to the debugger tab and change the debugger to "MinGW gdb Debugger"
I also had to make sure a copy of SDL.dll was in the ffmpeg directory.
Phew, what an ordeal. That all worked for me, hopefully it will work for you too!
install last MSYS and MinGW
Cf.
link text
When I run the debugging I get "gdb.exe has encountered a problem and needs to close...."
I updated to gdb 6.8 and succeeded to debug