Re: Octave/Matlab gcc front end?

[Ted Harding]

( Re Message From: John Eaton )

> First, I would like to improve Octave's ability to load externally
> compiled functions.  If dld is never going to be ported to more
> systems, it would probably be good to use dlopen, or other
> system-specific utilities.  I think that would allow dynamic linking
> on most systems of interest.  Is there anyone out there who has
> experience using these tools who would be willing to contribute code,
> or adapt existing solutions from other systems like perl or gnans?

May I ask a naive question? In Matlab, the MEX file mechanism, though
needing some care, works very straightforwardly. Knowing the structures
and parameter-passing method used by Matlab, you write (in FORTRAN or C) a
program to do what you want and pass back the results. You then compile
this into object code, using a couple of Matlab-supplied libraries.  This
works very smoothly even in DOS: the batch file (from 1988!) for Turbo C
is simply

C:\TC\TCC -a -c -f87 -ml -N- -IC:\TC\INCLUDE %1
IF ERRORLEVEL 1 GOTO DONE
C:\TC\TLINK C:\ML\MEX\CMEX+C:\TC\LIB\C0L+%1,%1.MEX @C:\ML\MEX\TCMEX.RSP /c /m;
C:\ML\MEX\PROT_MEX %1
DEL %1.OBJ
:DONE

(The program protmex.exe does something which I've forgotten, but it's
supplied.)

Matlab seems to have a builtin method of accessing the resulting .MEX object
file (over-lay style, I suppose). Although this is not quite the same as
"installing a new built-in function on the fly", it works very well.

Now my naive question is: If it is this simple in DOS/Matlab, why does it
seem to be so problematic with UNIX/octave, with fuss about dld etc?

Please note I'm not suggesting there is no problem: but I'm interested to
know. Or are we being more ambitious than Matlab+MEX?

Ted.                                    (address@hidden)