> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module
> and C interop being added to the Fortran 2003 standard. No more ugly guess
> work, hackery, etc.
> AFAIK, there is pretty good support for this among compiler vendors, so long
> as you have a recent release.
>
I am trying to integrate a FORTRAN library into our C++ project. I have
used the following in our CMakeLists.txt file:
include(CMakeAddFortranSubdirectory)
cmake_add_fortran_subdirectory(src
NO_EXTERNAL_INSTALL
PROJECT EMSoftLib # project name in toplevel CMakeLists.txt in lapack
On 11/01/2016 17:58, Michael Jackson wrote:
and we call the function from our C code like the following:
SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
You need to use the macros here too.
Regards
Bill Somerville.
--
Powered by www.kitware.com
Please keep
On 11/01/2016 18:48, Michael Jackson wrote:
Do other FORTRAN compilers support this “bind(C)” thing
I can only vouch for gfortran but yes that is the idea.
Regards
Bill Somerville.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Actually,
If we just use the following:
SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
and the same declaration in a .h file then we can link and execute just fine.
My question now would be:
Do other FORTRAN compilers support this “bind(C)” thing, such as Intel
On 11/01/2016 17:58, Michael Jackson wrote:
subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e,
mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')
Surely if you use bind(C) you need do no more than extern "C" the
declaration when compiling C++. I thought bind(C) meant mangle
--Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
Sent: Monday, January 11, 2016 11:48 AM
To: Bill Somerville <b...@classdesign.com>
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling
Actually,
If we just use the following:
Single
> On Jan 11, 2016, at 11:31 AM, Zaak Beekman wrote:
>
>
> So if I require Fortran 2003 for our fortran codes then this whole ?fortran
> name-mangling? thing becomes a moot point, i.e. I do not have to actually
> worry about it at all for our project. Just have to keep the
11, 2016 12:11 PM
To: Thompson, KT <k...@lanl.gov>
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling
So if I require Fortran 2003 for our fortran codes then this whole “fortran
name-mangling” thing becomes a moot point, i.e. I do not have to actually worry
about it at all f
> So if I require Fortran 2003 for our fortran codes then this whole
> ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to
> actually worry about it at all for our project. Just have to keep the C
> header consistent with the FORTRAN functions, but that part is on our devs.
>
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville <b...@classdesign.com>
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
>
> Actually,
> If we just use the following:
>
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, m
On 1/11/2016 2:31 PM, Zaak Beekman wrote:
Happy hacking!
FYI:
There is a longer version of that blog found here:
http://www.netlib.org/lapack/lawnspdf/lawn270.pdf
bind(c) sounds like a good idea if your compilers support it.
-Bill
--
Powered by www.kitware.com
Please keep messages on-topic
Brad King wrote:
My guess is that CMake is generating a bad .vfproj file
It was generating a bad file in the case of per-source compiler definitions.
perhaps
due to the presence of both C and Fortran sources in one of the
detection project targets.
This was not the cause because there are
Brad
Great. Thanks very much for looking at it.
JB
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: 02 December 2009 17:57
To: Biddiscombe, John A.
Cc: cmake@cmake.org
Subject: Re: [CMake] Fortran name mangling
Brad King wrote:
My guess is that CMake
First off, I'd like to say thanks to whoever is responsible for the huge
improvements in Fortran support in cmake-1.8.0. I've got most of the hdf5
Fortran testing framework essentially running smoothly on win32 intel visual
fortran 11.x - no changes necessary to the default Fortran flags and
Biddiscombe, John A. wrote:
However, for unknown reasons, when I use this code on the win32 machine
which is compiling the primary fortran projects happily, this happens
[snip]
The question is, why is/are the solution files being corrupted when
running in the CFortranInterface try compile
16 matches
Mail list logo