problem of compilation with intel fortran

[oswa]

Hello,

I have a C ++ program which uses glut and I compiled with Intel Fortran, in the compilation I had of problem of link's edition .

please how make the link's edition of glut in the bat file ( opengl32.lib, glut32.lib ,glu32.lib and glut.h, glu.h , gl.h and open32.dll, glut32.dll, glu32.dll)?

my linker error output is:

ExCarre.obj : error LNK2019: unresolved external symbol glutInit referenced in function main

VBATCH00.exe : fatal error LNK1120: 18 unresolved external

here is the content of the BAT file for compiling the code:

cl /nologo /c ExCarre.cpp

rem ifort /nologo /FeVBATCH00.exe /D_CRT_SECURE_NO_DEPRECATE ExCarre.obj %LINK_FNL% %LINK_*_SHARED_*%

ifort /nologo /FeVBATCH00.exe /D_CRT_SECURE_NO_DEPRECATE ExCarre.obj %LINK_FNL%

DEL ExCarre.obj

Thanks in advance

[mecej4]

You do not say anything about compiler error messages, so I take it that the GLUT header files are specified either using the INCLUDE environmental variable or other means.

You simply need to replace

ifort /nologo /FeVBATCH00.exe /D_CRT_SECURE_NO_DEPRECATE ExCarre.obj %LINK_FNL%

by

ifort /nologo /FeVBATCH00.exe ExCarre.obj %LINK_FNL% opengl32.lib glut32.lib glu32.lib

and make sure that opengl32.dll, glut32.dll, glu32.dll are accessible throuth the PATH environmental variable.

[oswa]

Thank you for your quick response.

But i tried to copy the opengl32.dll, glut32.dll, glu32.dll in the compilation path unsuccessfully. when these libraries are in the compilation path, the compilator logically recognize them. But clearly it is not the case.
would you please show me the way to make sure that the libraries are accessible through the path environmental variables?

PS: the error i get is the following:

ExCarre.obj : error LNK2019: unresolved external symbol glutInit referenced in function main

VBATCH00.exe : fatal error LNK1120: 18 unresolved external

[mecej4]

You are confusing DLLs and their corresponding stub libraries There are very few linkers in the Microsoft world that can directly use existing DLLs as input to a link step.

Assuming that you have both iterms of the matched pair (opengl32.dll, opengl32.lib), and so on, consider the following. The DLLs are of no use during the linking of your applications. It is only the .lib files that are used. Do you have them?

After the linking is completed, the .lib files are no longer needed until/unless you link again.

After successfully linking, to run your application, you now need the .dll files.

If you do not have the import libraries opengl32.lib, etc, you can build them from the DLLs by constructing a module definition file (.def). Details can be found at the MSDN site.

[oswa]

hello,

in the repertoire of work, i put files .dll ( opengl32.dll, glut32.dll, glu32.dll) and files .lib (opengl32.lib, glut32.lib, glu.lib) and files .h (glut.h, gl.h, glu.h).

and i change the file.bat by:

cl /nologo /c ExCarre.cpp

rem ifort /nologo /FeVBATCH00.exe /D_CRT_SECURE_NO_DEPRECATE ExCarre.obj %LINK_FNL% %LINK_*_SHARED_*%

ifort /nologo /FeVBATCH00.exe ExCarre.obj %LINK_FNL% OPENGL32.LIB glut32.lib GLU32.LIB

DEL ExCarre.obj

but it stays the same error:

ExCarre.obj : error LNK2019: unresolved external symbol glutInit referenced in function main

VBATCH00.exe : fatal error LNK1120: 18 unresolved external

[mecej4]

You are doing mixed-language programming, because you are calling C functions in the GLUT libraries in your Fortran code.

There is an entire chapter on mixed-language programming in the IFort User Guide, which will help you.

Three main reasons why you cannot simply compile C code using CL.exe and Fortran code with IFort and link the .obj files:

(i) the name decoration: by default, the Fortran code expects "_GLUTINIT", but the library provides "glutInit"; there are compiler and linker switches to help in this regard; Fortran-2003 has C Interoperability features.

(ii) care is needed to map C function argument expectations to Fortran types, especially strings; again, the C Interoperability in Fortran-2003 is there to help.

(iii) the default convention for passing arguments is, in a nutshell, by value in C and by reference in Fortran, but details are OS- and compiler-dependent.

If the rules of mixed-language programming are not followed correctly, you may not be able to compile and link, or, worse, you may produce an .EXE file "without any errors" but it will crash when run.

What makes mixed language programming a bit of a challenge for the beginner is that there are many ways of accomplishing the task.

[oswa]

Thank you again.
The mixed language programming isn't problem for us because we already succeeded in building executables containing both fortran anc C and even C++ programs.
C and C++ programs are compiled with cl, fortran programs are compiled with intel fortran, and the whole application is builded with intel fortran.
Now if we want to use new feature contained in the opengl libraries, we succeeded to make object files from c++ programs linked to opengl functions, but when building the whole application with intel fortran we find the errors mentionned above: unresolved external symbols. So, we guess that in the build instructions using ifort, there is a missing link to the opengl library or something like that. But programming in mixed-language does not constitue a problem itself.

[Martyn_C_Intel]

Still, it might be a useful precaution to run DUMPBIN /SYMBOLS /OUT to verify that the symbols match exactly. You can use FIND to search the output files. Easiest to start with static libraries, if you have them.

[oswa]

excuse me Martyn but i didn't get what you mean. what do you mean by running this instruction? what output files you are referring to ?
wouldyou pleasegive more explanation?

[TimP]

Martyn is pointing out that you could use dumpbin, or other similar utilities, to examine your .obj files and see the actual spelling of the linkage symbols, in case you have a discrepancy between languages. You could resolve such a discrepancy by using iso_c_binding, or by any of the legacy methods, including changing the spelling of your C function name. This also would help you catch a missed extern "C".

[mecej4]

Your example is rather simple, since only one object file and one library file are of concern.

dumpbin /symbols ExCarre.obj | find /i "glutinit"

will show the unsatisfied external symbol, which will be "glutinit" with, perhaps, some changes in case and added underscores.

Similarly,

dumpbin /symbols glut32.lib | find /i "glutinit"

will show the function entry point in the library glut32.lib. If the two versions of "glutinit" do not match as to case and underscores, you may follow Tim's advice (i.e., using suitable name decoration, or using Fortran 2003 interoperability features).

However, I note that in your example neither Fortran nor IMSL may be required for linking, since ExCarre.obj was compiled from a C++ source and may contain calls only to GLUT/OpenGL routines.

[oswa]

hello,

i have the same problem, please help me?

[mecej4]

A number of suggestions and recommendations were given by various people in this thread. It is customary for the original poster (you) to try out these suggestions, or to provide a cogent statement as to why the suggestions and recommendations are not acceptable. Failing that, there is nothing new to say about this "problem".