Sorry, I should read stuff more carefully, I just plain overlooked
that error message. I'm not sure what might be the reason for it. I'll
have to investigate. However, if you don't plan to call module-
functions from C, you should be fine.
Michael
On 23. Aug, 2009, at 13:02, Dominik Szczerba wrote:
Hmmm I dont understand. SET(FUNCTIONS...) does not influence
anything. The messages I get are identical as before, with the only
difference that the myfconfig.h now has something meaningful inside:
#define myfFUNCTIONS functions_
However, the errors:
-- Failed to find C binding to Fortran module functions.
-- Failed to find Fortran module linkage
-- created /home/domel/build/solve/myconfig.h
are still there. Any valuable ideas?
- Dominik
Michael Wild wrote:
I think you called the CREATE_FORTRAN_C_INTERFACE function
incorrectly. The second argument needs to be the name of a
variable containing a list of function names:
SET( FUNCTIONS cross )
CREATE_FORTRAN_C_INTERFACE( myf FUNCTIONS $
{CMAKE_CURRENT_BINARY_DIR}/ myconfig.h )
Michael
On 22. Aug, 2009, at 20:24, Dominik Szczerba wrote:
Of course, you are right - not about ifcore that is resolved by
ldd, but about the multibyte magic. I applied your patch. Now I
get:
-- checking Fortran function linkage: sub_
-- found Fortran function linkage
-- checking Fortran function with _ linkage: my_sub_
-- checking Fortran module linkage: test_interface$sub
-- checking Fortran module linkage: TEST_INTERFACE_mp_sub
-- checking Fortran module linkage: _test_interface__sub
-- checking Fortran module linkage: __test_interface__sub
-- checking Fortran module linkage: __test_interface_NMOD_sub
-- checking Fortran module linkage: __test_interface_MOD_sub
-- Failed to find C binding to Fortran module functions.
-- Failed to find Fortran module linkage
-- created myfconfig.h
The content of myfconfig.h file:
/* This file is automatically generated by CMake, DO NOT EDIT.
It contains a mapping from Fortran functions so they can
be called from C or C++. */
Where do I go from here?
Many thanks,
Dominik
Michael Wild wrote:
As I said, FortranCInterface.cmake is buggy as it doesn't pass
the CMAKE_Fortran_FLAGS and CMAKE_EXE_LINKER_FLAGS variables to
the TRY_COMPILE project. If you have to set these in order to
compile/ link a mixed-language program, it fails. Come to think
of it, in your case the ifcore library will also be missing, so
probably something like a CMAKE_REQUIRED_LIBRARIES variable
will also be necessary.
Michael
On 22. Aug, 2009, at 15:40, Dominik Szczerba wrote:
I naively tried:
INCLUDE(FortranCInterface)
CREATE_FORTRAN_C_INTERFACE(myf cross myfconfig.h)
to get:
-- checking Fortran function linkage: sub_
-- checking Fortran function linkage: _sub_
-- checking Fortran function linkage: __sub_
-- checking Fortran function linkage: SUB_
-- checking Fortran function linkage: _SUB_
-- checking Fortran function linkage: __SUB_
-- checking Fortran function linkage: sub
-- checking Fortran function linkage: _sub
-- checking Fortran function linkage: __sub
-- checking Fortran function linkage: SUB
-- checking Fortran function linkage: _SUB
-- checking Fortran function linkage: __SUB
CMake Error at /usr/local/share/cmake-2.6/Modules/
FortranCInterface.cmake:169 (message):
Could not find fortran c name mangling.
Call Stack (most recent call first):
CMakeLists.txt:34 (create_fortran_c_interface)
I have C CXX and Fortran enabled in the 'project' call. Using
icpc/ ifort 11.x
- Dominik
Dominik Szczerba wrote:
Hi Michael,
Michael Wild wrote:
Hi Dominik
Concerning the flags: you should add the -no-multibyte-chars
to the CMAKE_CXX_FLAGS variable. This will get prepended to
all CMAKE_CXX_FLAGS_{RELEASE,DEBUG,...} flags, since you
don't want this flag to be used for the Release
configuration exclusively, but for all configurations.
Thanks for the clarifications.
Linking against ifcore using the C++ compiler only works if
it is on the search path (probably by sourcing
ifortvars.sh), otherwise you'll have to specify it's full
path. I think, Intel recommends using the the Fortran
compiler for linking instead, and passing it the -cxxlib
and -nofor_main flags (those are the correct names now, I
looked them up ;-)).
I see, will maybe try some day. However, I have no problem
linking for the moment.
On Mac platforms there is another problem: By default the g+
+ compiler generates 32-bit code, while the Intel Fortran
compiler generates 64- bit code (very annoying).
If you try to use FortranCInterface.cmake, be aware that it
is quite buggy, as it doesn't pass the CMAKE_*_FLAGS to
the try_compile calls. Further it doesn't ensure that the
C language is enabled, altough it is calling try_compile on
C code! I'll file a bug report with an attached patch for
that.
This is new to me. Sounds like automatic handling of calling
decorations. Would be great! Are there any examples how to use
it? Do I still need it when I know the mangling scheme
myself? Can I set the pre/suffixes myself in some elegant
manner? Currently I am just hacking on my own, so indications
how to position myself for the future are very welcome.
Thanks,
Dominik
All the best
Michael
On 22. Aug, 2009, at 13:35, Dominik Szczerba wrote:
Here the report of my tests:
Just ignorant approach (don't google):
It works out of the box on linux with intel compilers 10.x.
Just add Fortran to the languages in the project signature
and add STUFF.F90 to the source files. You need to link to
ifcore library though.
It does not work out of the box with the compilers 11.x.
Here the ignorant approach failed. The errors were like:
-- Check for working CXX compiler: /usr/local/bin/icpc-11.0.083
-- Check for working CXX compiler: /usr/local/bin/
icpc-11.0.083 -- broken
CMake Error at /usr/local/share/cmake-2.6/Modules/
CMakeTestCXXCompiler.cmake:25 (MESSAGE):
The C++ compiler "/usr/local/bin/icpc-11.0.083" is not able
to compile a
simple test program.
It fails with the following output:
Change Dir: /home/domel/build/solve/CMakeFiles/CMakeTmp
Checking by foot what the compilers at all say during
compilations I found:
icpc-11.0.083 -c test.cxx
Catastrophic error: could not set locale "" to allow
processing of multibyte characters
Googling reveals a bug in the compiler to be circumvented
with adding '-no-multibyte-chars' to the compiler
switches. However, adding this to my
CMAKE_XXX_FLAGS_RELEASE (my CMAKE_BUILD_TYPE is RELEASE)
does not help. I must now either specify CMAKE_XXX_FLAGS
explicitly on the commandline or in the cache. Probably
because cmake uses default flags (CMAKE_XXX_FLAGS) for
compiler checks, even if CMAKE_BUILD_TYPE is explicitly
set release/debug (as well as corresponding release/debug
flags).
Maybe cmake should use compiler flags as defined by
CMAKE_BUILD_TYPE to check for compilers?
- Dominik
Dominik Szczerba wrote:
Michael,
Many thanks for the feedback.
What I am doing with a GNU makefile so far is compile just
one file with the fortran compiler use C++ linker to link
all object files as usual.
A comprehensive solution I would expect in cmake would be
1) nothing (.f90 file is understood) or something along
the lines of setting the file properties (sort of 'to be
compiler with' flag)...
- Dominik
Michael Wild wrote:
On 21.08.2009, at 17:57, Dominik Szczerba <[email protected]
wrote:
I want to compile one file with fortran compiler (intel)
and link with the rest of my project. Will the latest
cmake allow to fully cmakify such scenario?
Hi Dominik
If I remember correctly, you'll have to set the
LINK_LANGUAGE property of your target to Fortran and
then ensure that the Fortran linker also links against
the C++ standard library. For Intel this would be -stdc+
+ (or some such). If you are creating an executable,
depending on where your main-function is defined, you
might also need to tell the linker to not add a Fortran
main- function, the flag is called - nofor_main if I
remember correctly. Otherwise the ifort man-page will
tell you :)
HTH
Michael
--
d o m i n i k s z c z e r b a , p h d . . . . . . . . . . .
c o m p u t a t i o n a l l i f e s c i e n c e g r o u p
. . . . . . . i t ' i s r e s e a r c h f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch
--
d o m i n i k s z c z e r b a , p h d . . . . . . . . . . .
c o m p u t a t i o n a l l i f e s c i e n c e g r o u p
. . . . . . . i t ' i s r e s e a r c h f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch
--
d o m i n i k s z c z e r b a , p h d . . . . . . . . . . .
c o m p u t a t i o n a l l i f e s c i e n c e g r o u p
. . . . . . . i t ' i s r e s e a r c h f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch
--
d o m i n i k s z c z e r b a , p h d . . . . . . . . . . .
c o m p u t a t i o n a l l i f e s c i e n c e g r o u p
. . . . . . . i t ' i s r e s e a r c h f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
