Re: oct (and mex) files for different architectures

[John Swensen]

On Sep 12, 2011, at 9:53 AM, Jordi Gutiérrez Hermoso wrote:

> 2011/9/12 Richard Crozier <address@hidden>:
>>  On 12/09/2011 14:30, Jordi Gutiérrez Hermoso wrote:
>>> On 12 September 2011 08:14, Richard Crozier <address@hidden> wrote:
>>>> On Matlab, I can compile several different mex files for different machine
>>>> architectures and Matlab will call the appropriate one for the local setup.
>>>> The compiled mex files are given appropriate extensions e.g. mexa64 for
>>>> 64bit linux, mexglx for 32 bit linux, mexw32 for 32 bit windows etc.
>>>> 
>>>> Is the equivalent possible for oct files (or mex files created in Octave)?
> 
>>> Not currently, no. I find that putting the architecture in the
>>> filename extension is a little weird to begin with. Why don't you see
>>> .exe64 and .exe extensions for Windows executables? Can't you just
>>> recompile and distribute your oct files for the architecture you need
>>> them? I get the feeling that Matlab lets you do that because people
>>> don't like recompiling and/or don't like source code.
> 
>> I have matlab instances running on several different platforms all
>> accessing the same code directory simultaneously (hosted on a SAMBA file
>> share).
> 
> And what do you do about the Octave instances? Do you have
> octave.exe64 and octave.exe32 running as well?
> 
> Also, the architecture is not the biggest problem. Even for the same
> architecture, you would have to recompile your octfiles if your
> machines have slightly different libraries on the OS you're compiling
> for. So you would need .oct64deb-6.0, oct64ubu-11.08, .oct64fedora-13
> and .oct64suse-5.
> 
> I just don't see how filename extensions can solve this problem. It
> might solve it for Windows, but I don't see how it would work for
> other things. Octave runs on a lot more architectures than Matlab too;
> and we compile it for all 11 architectures of Debian; coming up with a
> filename extension per architecture seems unwieldy.
> 
> I think the solution for now, even if it's inconvenient, is to put
> your oct files in directories that have a filename extension specific
> to the architecture you care about and in your m-scripts you
> conditionally pick to load the directory based on system information
> (perhaps after running system("uname -a") or similar).
> 
> - Jordi G. H.

Octave is already loading the OCT/MEX files dynamically.  This is simply using 
the architecture and binary that is currently being run to determine which 
OCT/MEX file to load.  This makes a lot of sense for binary distributions (the 
developer can release all platforms to end-users rather than telling them to 
"learn how to compile it yourself"). I'm not saying I know how to determine a 
binary's architecture at runtime (or have time to do it), but clearly Matlab is 
doing it and I'm sure it isn't as hard as one might think (you may even be able 
to just use various #defines from the autoconf process).

John Swensen