Finding IVF in the drop-down menu of the "Rulers"

Finding IVF in the drop-down menu of the "Rulers"

Recently I've installed the Intel Fortran Compiler on my IMac running on Mac OXS 10.5.2 (Leopard). The problem is that I could not find the Intel Fortran Compiler in the drop-down menu of the "Rulers" when choosing a compiler for "Fortran source files" in Xcode 3.0. Could you help me with this problem?

30 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

what version of the Intel Fortran compiler do you have? ifort -V

We have seen this with customers who install the iPhone SDK, bringing Xcode to v3.1. You didn't install the iPhone SDK did you?

You can try to uninstall/reinstall the compiler: as admin or root user from a command line:


and then try the installation once again.


I haven't heard back from you on this issue - did my suggestions help? Are you able to use Ifort under your Xcode?



Hi Ron,

I could not open this website on my Mac. Now I am using a PC to get back to you. The problem is still there. My intel fortran version is 10.0. In addition, I found that ifort cannot compile *.F files. Is there any way to compile these old FORTRAN files using ifort.



For Leopard systems, you must install one of the versions of the Compiler, the most recent version is recommended. The versions do not support Leopard, nor Xcode 3.0. The latest 10.1 compiler versions are available for download from Intel's Registration Center for any customer with an active Mac OS* X compiler license.


Thanks. Now I have installed the 10.1 version of the compiler and can find the intel compoiler under "Rules" of XCode 3.0. But the problem is Xcode gave a warning "no rule to process file '$(PROJECT_DIR)/main.f90' of type sourcecode.fortran.f90 for architecture ppc" when I tried compiling a test fortran code under Xcode. I did add a new Rule for the "Fortran source files" using "Intel@ Fortran Compiler 10.1 (Preview)" under the "Target".


PowerPC (ppc) is an inappropriate Architectures setting for the Intel Fortran compiler for Mac OS.

The only appropriate Architectures setting is Intel (via the check box) which renders i386 in the Value field for the Architectures setting in the Target Info window, which invokes the IA-32 compiler, or via a manual entry of x86_64 which invokes the Intel 64 compiler.

To set Architectures appropriately please try the following:

1. From the Xcode IDE, under Groups & Files -> Targets, right-click on the name of the target executable and select Get Info

2. In the Target Info window that appears, set the top Configuration pull-down selection to All Configurations using the up/down arrows at the right-edge of the cell

3. Set the Collection pull-down selection to Architectures using the up/down arrows at the right-edge of the cell

4. You have two options to set the Architectures setting depending on the compiler you wish to use:

a. Double left-click on the Setting Architectures. A check-box selection sub-window will appear. Make certain that only Intel is selected, and then click Ok. The Value of i386 should appear. (You can also left-click once on Architectures and use the Edit button to raise the same check-box sub-window)

b. Or Double left-click on the Value field to enter edit mode and enter the x86_64 manually

5. Dismiss this Target Info window, and try the Build and Go button from the main Xcode IDE


Thanks a lot. It works. You are really kind and helpful. One more question - when building the source files I got an error "abild.F(6): #error: can't find include file: param.h." The file "param.h" actaully is in the same subfolder as the file "abild.F". I don't know why "abild.F" cannot find "param.h"?


Glad to read that helped. I would expect the compiler to find an include file when resident in the same subfolder as the using source file.

I have not been able to create a scenario where an include file is not found when resident in the same subfolder as the using source file (sub.F in my example) and using either INCLUDE or #include.

One scenario where I can create this error involves using a non-existent include file, so you might double-check that the include file is truly resident in the same directory as the using source file or that there isnt a typo in the INCLUDE or #include statement in the using source file.

Are you using

#include param.h

and expecting the preprocessor to include the file, or are you using the Fortran INCLUDE statement?




Perhaps there is something within the Xcode project settings or the project directory structure that is hiding the root cause of the error. There is nothing visibly incorrect in the code sample included. I can successfully use the param.h in my example sub.F after creating an appropriatedefines.h too.

I know you indicated the files are in the same directory, but you did not indicate if you are seeing those in the same directory under a console/terminal window or if you actually verified the path under Xcode. So, try double-checking the path to the files under Xcode. Under Groups & Files, right-click on the source file and select Get info. Check the path to both param.h and abild.F and ensure they are in the same directory.

If those are the same directory then I am not sure how to advise or diagnose the issue without having the complete contents of the Xcode project directory to work with. If you wish to share that in this public Forum you can attach a gzipped tar file of the complete Xcode project directory here. If not, then feel free to create an Intel Premier issue ( and attach the gzipped tar file to the Premier issue.

Hi Kelvin,

I tried to attach the file with this post, but failed to do so. It might be because my file is too large, about 11MB. I could not login the too. Is there any other way so that I can send it to you?

Thanks for your time and help.


Try dropping the file onto our FTP server as follows from a terminal or console window:

1. Enter: ftp

2. Login using anonymous as a username and provide your full email address for the password

3. Enter: bin

4. Enter: cd /pub/incoming

5. Enter: put

Please note, files on our FTP server are hidden from view and scrubbed after 24 hours. I need to know exactly the you used above.


Similar to what you described for abi1d.f, when I try to build the compilation fails because afenparam.F cannot find the various include files like: param.h, geom..h, xsec.h and others. All these files reside in the same parcs sub-directory. Compilation via the command-line works fine from inside this sub-directory, but under Xcode, while it provides a relative path to the source file being compiled, e.g. ../V5.090/parcs afenparam.F, it does not add a relative I include path of ../V5.090/parcs to the ifort command so the include files are not found.

It is unclear to me if this is expected behavior or not. I need to modify my example to work with it a bit more, and discuss this with our Xcode integration developers.

To get you past this, under the Xcode property settings for the trace target in the Intel Fortran Compiler 10.1 Preprocessor section, please set the Additional Include Directories to: ../V5.090/parcs

The next situation you will need to address involves the MODULE usage in this application.

The application has several files containing MODULE definitions. These files must be compiled first to ensure the associated .mod files are available for other source files that USE the defined modules.

I tried establishing the necessary compilation order for you but I do not have PVM available so I cannot get past the missing the fpvm3.h include file.

Under Xcode, source files are compiled in the order they appear under the Compile Sources for the given Target. Therefore, to ensure the source files containing MODULE definitions are compiled first, you must rearrange the source files under the Compile Sources and list the source files containing modules ahead of other source files.

I was able to establish is at least this initial ordering of files that must appear first under Compile Sources:











I wish I could have provided the complete file list but in the absence of PVM that was not possible.

To establish the compilation order, unless you know the module usage dependencies and can arrange the source files in the necessary compilation order under the Compile Sources, one method to discover the dependency order is to try the build and then address compilation errors which report an Error in opening the compiled module file. Check INCLUDE paths [Module name]. This error provides the name of the referenced MODULE; therefore, knowing the module name you can locate the source file containing the module definition that must be compiled ahead of the source file that generated this error and thus make the necessary ordering adjustment to the source files listed under Compile Sources.

I hope this helps. Please do keep us posted on your progress.


Hi Kelvin,

Thanks a lot for your help. It seems to be impossibleand impractical to establish all the compilation order by hand since there are too many source files. It would be very helpful if the Xcode/Compiler can do this automatically. Yesterday I managed to sort our the compilation order and compiled all the files except one. Could you take a look at this issue? I know all the filescan be compiled with a script under the command line, including this C file. Please see the attachment.

I really appreciate your kind help. I've learned a lot from you.



Downloadapplication/zip Archive.zip15.24 KB

Hi Dean,

Neither Xcode nor the compiler can guess what actual source file(s) contain MODULE definitions in order to compile those first; nor can either try to seek out a source file containing the module definition corresponding to a USE statement seen during parsing of a source file.

Establishing the compilation order under Xcode is the same requirement that exists when using a command-line driven compilation method such as a shell script or a makefile. The programmer must still ensure that source files containing MODULE definitions are compiled first. It is my understanding this is a by-product of how MODULEs work and this is not unique to the Intel Fortran compiler.

There are tricks one can use under Xcode to group source files containing MODULE definitions into a dependant library of the Target executable. This way the dependant library is built accordingly when the Target is built and this helps separate source files containing MODULE definitions from other source files. You can use a similar structure with command-line driven methods too.

As for the compilation of the attached C file, I dont know what errors you experienced, but the file compiles fine via the command-line with either the Intel C++ compiler or GCC as follows:

icc -c -DMACOSX CIpcFunc.c

gcc -c -DMACOSX CIpcFunc.c

Under Xcode, make certain you add the MACOSX to the GCC 4.0 Preprocessing Preprocessor Macros Build setting.

The other compilation errors you will see under Xcode relate to your Xcode project, specifically the xdr group which contains the header: ../V5.090/xdr/rpc/NETDB.H All the header files under the xdr/rpc sub-directory have comments indicating they are applicable to Windows NT.

Under Xcode, CIpcFunc.c compiles clean when using the system version of: /usr/include/netdb.h

It appears all the source files contained under the xdr group are for Windows NT too, so something you may need to consider long-term is removing the xdr group from your Xcode project if it is not applicable to Mac OS X.

Something quick and easy you can do to avoid ../V5.090/xdr/rpc/NETDB.H from being used is to just rename the xdr sub-directory to xdr_sav and then recompile the CIpcFunc.c under Xcode. That effectively makes the files under xdr inaccessible to Xcode so GC
C uses the system header: /usr/include/netdb.h

Hope that helps.



Hi Dean,

You arenot bothering me. I'm happy to help. You have good questions and hopefully the answer will help others.

This latest error suggests a couple of things to check:

  1. I expect it does, but double-check that /Users/DW/Work/TRACE/test/ exists and is writable
  2. Recall you sent me a file named trace.tgz, so make sure you do not have a sub-directory named trace under the path note in 1 abovethat would conflict with Xcode trying to create an executable file by the same name. If so, just rename the sub-directory and retry the build.

Xcode can be a little tricky to get the hang of at first, but its pretty cool once you get over the initial navigation learning curve.



Hi Dean,

The current errors I see involve duplicate defined symbols that cause the link to fail.

The first involves three source files that each contain a PROGRAM statement and thus each defines the symbol _MAIN__. ~/V5.090/parcs/parcs.F, ~/V5.090/parcs/parcs_master.F, ~/V5.090/src/trac.f90

If you need parcs_master.F, then you must deal with the #ifdef appearing at the top of parcs.F to activate the subroutine entry point and not the PROGRAM statement. Defining TPMERGE has implications in other sections of parcs.F and a number of other source files so I cannot advise on whether you should enable that define or not. Given the code structure, that seems to be the intent of the programmer, however, there are other things going on here as discussed below.

Another duplicate symbol involves source files ~/V5.090/src/tdmr.f90 and ~/V5.090/parcs/TdmrM.F which both define the MODULE and symbol _tdmmrm._. According to the source code comments, TdmrM.F is intended for use when building the parcs.lib, so I presume this should not be compiled and linked as a part of the trace5 executable.

In looking at ~/V5.090/src/trac.f90, it seems perhaps this application contains source for two distinct components, a parcs.lib library and main trace executable. However, under your Xcode project the trace5 target is treating all the source under the parcs and src subdirectories as a single program, thus compiling all the source and linking all the objects into the single trace executable which leads to these duplicate symbol definitions.

It appears to me ~/V5.090/src contains source to the trace executable and ~/V5.090/parcs contains source to parcs.lib library that is linked to the trace executable. If so, then you need to create a new target to build the parcs.lib that is only associated with the source files residing in the parcs subdirectory. Then, make this library a dependant of the trace5 target. You do that by simply dragging the parcs.lib target to the trace5 target under the Link Binary with Library section. You must also then make certain the trace5 target is only associated with the source files residing in the src subdirectory.

I can try to help restructure the latest Xcode project you provided if I can get PVM on my system to enable me to compile this app. If you have PVM on your system in self-contained area, like /usr/local, that you can zip up and drop on our ftp server then I should be able to make use of that. Avoiding using an absolute path of /usr when creating the zip.

Hope that helps and Im sorry this just keep getting more complicated. Once you overcome the hurdle of structuring the Xcode project accordingly for the application you should be set.





It appears as if each library (liblibparcs.a & liblibtpr.a) has linked in a static instance of the Intel Fortran RTLs.

You could try rebuilding your static libraries and link them to the dynamic Intel Fortran RTLs.Im not sure if you under Xcode now or not. If so, set Intel Runtime Libraries to Dynamic Libraries under the Intel Fortran Compiler 10.1 (Preview) Runtime settings. If you are using the ifort command line now, then link with the option: -shared-intel

I do not have a mockup to test with so I do not know if the linker option, -multiple_defined suppress, might help with linking with the static Intel Fortran RTLs.



Hi Dean,

I appreciate the update and your efforts. I will help you get the app built/running with ifort.

Can you please provide me with the scripts for both GFortran and ifort?

It appears the forum only allows one file attach per reply, so if you want to zip those up together you can attach to a Forum reply or you are welcome to drop the file on our ftp server.

It appears the earlier build issues of duplicate Fortran RTL symbols may involve the use of libtool under Xcode versus ar to create the static libraries linked with trace. I will continue looking into this too.



Leave a Comment

Please sign in to add a comment. Not a member? Join today