> 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.
> Even
> 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 C header
> consiste
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 a
> 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.
>
11, 2016 12:11 PM
To: Thompson, KT
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 for our project. Just
--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
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling
Actually,
If we just use the following:
SingleEBSDPattern(ipar, fpar, ebsdPatt
ary 11, 2016 11:48 AM
> To: Bill Somerville
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
>
> Actually,
> If we just use the following:
>
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>
> and the same declaratio
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:
http://www.cmake.org/Wi
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 For
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 messag
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 the
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
LIBRARIES
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 Kin
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 ar
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 stag
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 det
16 matches
Mail list logo
