Re: [CMake] FORTRAN name mangling

2016-01-12 Thread Arjen Markus
> 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. >

[CMake] FORTRAN name mangling

2016-01-11 Thread Michael Jackson
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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville
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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville
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:

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Michael Jackson
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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville
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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Thompson, KT
--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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Damian Rouson
> 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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Thompson, KT
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

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Zaak Beekman
> 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. >

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread 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: > > SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, m

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Hoffman
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

Re: [CMake] Fortran name mangling

2009-12-02 Thread Brad King
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

Re: [CMake] Fortran name mangling

2009-12-02 Thread Biddiscombe, John A.
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

[CMake] Fortran name mangling

2009-11-25 Thread Biddiscombe, John A.
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

Re: [CMake] Fortran name mangling

2009-11-25 Thread Brad King
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