Home > Archive > Fortran > June 2007 > gfortran and Matlab
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gfortran and Matlab
|
|
|
| Has anyone managed to use gfortran to produce a mex file for Matlab?
I've tried to derive the necessary contents of the mexopts.sh file
from a based upon versions I have that work for g77 and g95. However,
I get the following run time error when the mex file is called ...
dyld: Symbol not found: __gfortran_internal_malloc
If some one call tell me which library the
"__gfortran_internal_malloc" function should be in, or better yet,
tell me specifically how to setup the mexopts.sh file to work with
gfortan, I'd appreciate it, much!
TiA
| |
| Tim Prince 2007-06-17, 4:20 am |
| Ben wrote:
>
> If some one call tell me which library the
> "__gfortran_internal_malloc" function should be in, or better yet,
> tell me specifically how to setup the mexopts.sh file to work with
> gfortan, I'd appreciate it, much!
>
gfortran normally has only 1 library of its own, usually something like
libgfortran.a or libgfortran.so, possibly with separate versions in
32-bit and 64-bit libraries, depending on your operating system. Did
you look there?
| |
| Gib Bogle 2007-06-17, 4:20 am |
| Ben wrote:
> Has anyone managed to use gfortran to produce a mex file for Matlab?
>
> I've tried to derive the necessary contents of the mexopts.sh file
> from a based upon versions I have that work for g77 and g95. However,
> I get the following run time error when the mex file is called ...
>
> dyld: Symbol not found: __gfortran_internal_malloc
>
> If some one call tell me which library the
> "__gfortran_internal_malloc" function should be in, or better yet,
> tell me specifically how to setup the mexopts.sh file to work with
> gfortan, I'd appreciate it, much!
>
> TiA
>
I can't help, but to satisfy my curiosity, would you mind telling me
what situation causes you to want to create a mex file from Fortran?
| |
|
| >
> I can't help, but to satisfy my curiosity, would you mind telling me
> what situation causes you to want to create a mex file from Fortran?
I don't have any reliable statistics, but there are many scientists
using Fortran.
I've noticed it is common to benchmark execution speeds of various c++
libraries for lapack and such to the Fortran versions. Fortran is
always a faster. A bit faster than best c++ implementations, and much
faster than the worst.
On the other hand, c++ has two significant advantages. First, there
are many more c++ programmers than Fortran programers, and 2nd, c++
syntax permits better architectural design of software projects.
For my application, speed is a big factor. Since a my mex-files are
all algorithm (they require no user interface, and no data storage)
using Fortran was an easy decision.
However, if my focus was on software and not on the algorithm, I'd
likely have opted for c++.
| |
|
| On Jun 16, 6:45 pm, Tim Prince <timothypri...@sbcglobal.net> wrote:
> Ben wrote:
>
>
> gfortran normally has only 1 library of its own, usually something like
> libgfortran.a or libgfortran.so, possibly with separate versions in
> 32-bit and 64-bit libraries, depending on your operating system. Did
> you look there?
Yes I did.
I'm liking to the library, *and* it does contain
"__gfortran_internal_malloc" :-(
I hate these kind of errors!
| |
| Beliavsky 2007-06-17, 4:20 am |
| On Jun 16, 7:58 pm, Ben <abbott...@gmail.com> wrote:
>
> I don't have any reliable statistics, but there are many scientists
> using Fortran.
>
> I've noticed it is common to benchmark execution speeds of various c++
> libraries for lapack and such to the Fortran versions. Fortran is
> always a faster. A bit faster than best c++ implementations, and much
> faster than the worst.
>
> On the other hand, c++ has two significant advantages. First, there
> are many more c++ programmers than Fortran programers, and 2nd, c++
> syntax permits better architectural design of software projects.
I think you mean language features, such as single and multiple
inheritance, templates, and the Standard Library, rather than syntax,
such as using semicolons to terminate statements and braces to delimit
blocks. Fortran 95 does not have inheritance but does have modules,
which I have found valuable. AFAIK C++ does not have the equivalent of
modules.
| |
| Gib Bogle 2007-06-17, 4:20 am |
| Ben wrote:
>
> I don't have any reliable statistics, but there are many scientists
> using Fortran.
>
> I've noticed it is common to benchmark execution speeds of various c++
> libraries for lapack and such to the Fortran versions. Fortran is
> always a faster. A bit faster than best c++ implementations, and much
> faster than the worst.
>
> On the other hand, c++ has two significant advantages. First, there
> are many more c++ programmers than Fortran programers, and 2nd, c++
> syntax permits better architectural design of software projects.
>
> For my application, speed is a big factor. Since a my mex-files are
> all algorithm (they require no user interface, and no data storage)
> using Fortran was an easy decision.
>
> However, if my focus was on software and not on the algorithm, I'd
> likely have opted for c++.
>
You explained why you are using Fortran (since this is a Fortran
newsgroup that was hardly necessary), but my question was why are you
creating a mex file from your Fortran code.
| |
| Brooks Moses 2007-06-17, 4:20 am |
| Gib Bogle wrote:
> You explained why you are using Fortran (since this is a Fortran
> newsgroup that was hardly necessary), but my question was why are you
> creating a mex file from your Fortran code.
There are a number of possible reasons for this sort of thing.
IME, one of the best of them is that (assuming one has a copy of Matlab)
it's a very convenient way to do work with large arrays of numbers in an
interactive scripting language. And, for exploratory work where one is
"playing" with a model and poking at it to try different parameters or
the like, it is tremendously useful to have a interactive rather than
batch processing style built into the language one's using.
In addition, it can also be important for combining the model with other
existing bits of code that are written in Matlab. :)
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Gib Bogle 2007-06-17, 10:06 pm |
| Brooks Moses wrote:
> Gib Bogle wrote:
>
> There are a number of possible reasons for this sort of thing.
>
> IME, one of the best of them is that (assuming one has a copy of Matlab)
> it's a very convenient way to do work with large arrays of numbers in an
> interactive scripting language. And, for exploratory work where one is
> "playing" with a model and poking at it to try different parameters or
> the like, it is tremendously useful to have a interactive rather than
> batch processing style built into the language one's using.
>
> In addition, it can also be important for combining the model with other
> existing bits of code that are written in Matlab. :)
>
> - Brooks
>
>
I have a lot of respect for Matlab, and use it from time to time. I've
also used Matlab as a UI to a numerical engine written in Fortran,
either using a DLL or transferring data through files. I am wondering
why one would go the route of translating Fortran code to mex, something
I've never done myself.
| |
|
| On Jun 17, 5:50 pm, Gib Bogle <b...@ihug.too.much.spam.co.nz> wrote:
> Brooks Moses wrote:
>
>
>
>
>
> I have a lot of respect for Matlab, and use it from time to time. I've
> also used Matlab as a UI to a numerical engine written in Fortran,
> either using a DLL or transferring data through files. I am wondering
> why one would go the route of translating Fortran code to mex, something
> I've never done myself.
The Fortran code is not translated to mex.
Rather mexing a Fortran program is analogous to having it run as a m-
file from within Matlab.
| |
|
| On Jun 16, 9:15 pm, Ben <abbott...@gmail.com> wrote:
> On Jun 16, 6:45 pm, Tim Prince <timothypri...@sbcglobal.net> wrote:
>
>
>
>
> Yes I did.
>
> I'm linking to the library, *and* it does contain
> "__gfortran_internal_malloc" :-(
>
> I hate these kind of errors!
Can anyone verify that they've successfully created a mex-file using
gfortan on Matlab 7+?
| |
|
| > Has anyone managed to use gfortran to produce a mex file for Matlab?
I don't have MATLAB and never used it, so I can't help with the details,
but... a web search returns many links of people having successfully used
gfortran with MATLAB, some of them on MacOS which is, I guess, your OS
(you didn't provide this information in your post). An example would be:
http://www-cse.ucsd.edu/~elkan/254/software.html
Please note that, in the link above, the paths in mexopts.sh are those of
the HPC binaries, which differ from the ones where the compiler is
installed by our link the GCC wiki provides.
--
FX
| |
| Jan Vorbrüggen 2007-06-18, 8:06 am |
| > On the other hand, c++ has two significant advantages. First, there
> are many more c++ programmers than Fortran programers,
Quite likely true.
> and 2nd, c++
> syntax permits better architectural design of software projects.
I don't think so, or only for a small value of "better" in any case. And F03
will remove a lot of what's left as a gap. All the other stuff in C++ just
gets in your way, IMO.
Jan
| |
|
| On Jun 18, 8:20 am, Jan Vorbr=FCggen <jvorbrueg...@not-mediasec.de>
wrote:
>
> Quite likely true.
>
>
>
> I don't think so, or only for a small value of "better" in any case. And =
F03
> will remove a lot of what's left as a gap. All the other stuff in C++ just
> gets in your way, IMO.
>
> Jan
Hi Jan,
I agree with you. I was only parroting what I've been told by my
colleagues with more c++ but less fortran knowledge than I.
I look forward to full F03 support from either g95 or gfortran.
| |
|
| On Jun 18, 5:46 am, "FX" <coud...@alussinan.org> wrote:
>
> I don't have MATLAB and never used it, so I can't help with the details,
> but... a web search returns many links of people having successfully used
> gfortran with MATLAB, some of them on MacOS which is, I guess, your OS
> (you didn't provide this information in your post). An example would be:http://www-cse.ucsd.edu/~elkan/254/software.html
>
> Please note that, in the link above, the paths in mexopts.sh are those of
> the HPC binaries, which differ from the ones where the compiler is
> installed by our link the GCC wiki provides.
>
> --
> FX
Thanks for the link. It is clear to me that some are able to
successfully use gfortran with Matlab on Mac OS X. Unfortunately, I'm
still stuck with the same error.
Its time for me to back up and try a simpler program ... *sigh*,
perhaps I'll go with yprime.f
| |
|
|
Ben wrote:
> On Jun 18, 8:20 am, Jan Vorbr=FCggen <jvorbrueg...@not-mediasec.de>
> wrote:
d F03[color=darkred]
ust[color=darkred]
>
> Hi Jan,
>
> I agree with you. I was only parroting what I've been told by my
> colleagues with more c++ but less fortran knowledge than I.
>
> I look forward to full F03 support from either g95 or gfortran.
ok, using yprime is a bad idea ... it uses Absoft F90 extensions that
are not compatible with gfortran ... off to write my own simple
example.
| |
| Greg Lindahl 2007-06-18, 10:08 pm |
| In article <1182027740.485234.100110@n2g2000hse.googlegroups.com>,
Ben <abbott.bp@gmail.com> wrote:
>If some one call tell me which library the
>"__gfortran_internal_malloc" function should be in, or better yet,
>tell me specifically how to setup the mexopts.sh file to work with
>gfortan, I'd appreciate it, much!
It's in libgfortran.a on my system, which happens to be in
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/.
-- greg
| |
|
|
Greg Lindahl wrote:
> In article <1182027740.485234.100110@n2g2000hse.googlegroups.com>,
> Ben <abbott.bp@gmail.com> wrote:
>
>
> It's in libgfortran.a on my system, which happens to be in
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/.
>
> -- greg
Thanks Greg
On my mac, it is in /sw/lib/gcc4.2/lib/libgfortran.a
However, I still get the run time error, even when I link using
-L/sw/lib/gcc4.2/lib -lgfortran
| |
| Jan Vorbrüggen 2007-06-19, 8:06 am |
| > However, I still get the run time error, even when I link using
> -L/sw/lib/gcc4.2/lib -lgfortran
I don't remember the original post...but a run time error would mean that not
the static library (.a) is used but the dynamic library (.so) which then
cannot be located (perhaps LD_LIBRARY_PATH not properly set). Just a stab in
the dark.
Jan
| |
|
| > I don't remember the original post...but a run time error would mean
> that not the static library (.a) is used but the dynamic library (.so)
> which then cannot be located (perhaps LD_LIBRARY_PATH not properly
> set). Just a stab in the dark.
I second that stab. I think the compiler and linker know where is the
library, but the runtime loader does not. The only thing where I beg to
differ from Jan is that, on Mac OS, the environment variable controlling
that is named DYLD_LIBRARY_PATH. Try setting that to the directory
/sw/lib/gcc4.2/lib
--
FX
| |
|
|
| paul.richard.thomas@gmail.com 2007-06-21, 10:06 pm |
| I am sorry about the long dealy - it has been a long time since I made
a .mex file.
On matlab 6.5/Tru64, I did the following at the Matlab command line:
> system('../irun/bin/gfortran -c yprime.f')
> mex -fortran yprime.o ../irun/lib/*.a
and the result worked fine and gave the same results as F90.
I could not remember for the life of me how to link the shared
libraries - I think that it is sufficient to extend the matlab PATH.
I just did not have time to check it out.
Paul
| |
|
| On Jun 21, 4:18 pm, paul.richard.tho...@gmail.com wrote:
> I am sorry about the long dealy - it has been a long time since I made
> a .mex file.
>
> On matlab 6.5/Tru64, I did the following at the Matlab command line:
>
>
> and the result worked fine and gave the same results as F90.
>
> I could not remember for the life of me how to link the shared
> libraries - I think that it is sufficient to extend the matlab PATH.
> I just did not have time to check it out.
>
> Paul
Thanks Paul,
In the past I was also successful with Matlab 6.5. Unfortunately, I no
longer have a working installation of that version, and the 7.x
versions for the Mac have a yprimefg.f gateway that is not f90
compliant (works only with the Absoft compiler).
Any chance you can post yprimefg.f from Matlab 6.5?
TiA
| |
| nf.editor@gmail.com 2007-06-27, 4:18 am |
| Ben,
> Any chance you can post yprimefg.f from Matlab 6.5?
I am out of town, right now. Hence the delay in replying and the
inability to get the source to you.
Paul
| |
|
| On Jun 27, 2:52 am, nf.edi...@gmail.com wrote:
> Ben,
>
>
> I am out of town, right now. Hence the delay in replying and the
> inability to get the source to you.
>
> Paul
Hi Paul,
Thanks for following up.
I've managed to answer my own question. I've posted some detail on
compiling mex-files using Matlab's mex function and g95/gfortran. I've
also been successful writing my own makefile for compiling mex-files
using both g96/gfortran.
I plan to post the details on that here once I complete a bit more
testing.
|
|
|
|
|