Thread Subject: Last drop in a user's patience

I have a many-many-MANY months*hours working time soft that works up till R2008a.
Now R2008b simply says things like this

Warning: Calling MEX-file 'C:\SVN\mironeWC\lib_mex\set_gmt.dll'.
MEX-files with .dll extensions will not execute in a future version of MATLAB.
Warning: Calling MEX-file 'C:\SVN\mironeWC\mexnc.dll'.
MEX-files with .dll extensions will not execute in a future version of MATLAB.

and the program doesn't work anymore (no more or less, it just crashes).
No future, just right now.

ARE DLLs DEMONIC?

SORRY BUT THAT WAS THE LAST DROP IN THE POOL (NOT THE GLASS).
NO MORE PATIENCE TO THE TMW NOTION OF BACK/FORTH COMPATIBILITY

I'M REALLY, BUT REALLY, PISSED OFF WITH TWM NOTION OF BACKWARD COMPATIBILITY

I ALSO REMOVED ALL MY CONTRIBUTIONS FROM THE FEX

Joaquim Luis

"Joaquim Luis" <jluis@--ualg--.pt> wrote in message <gflcij$3rm$1@fred.mathworks.com>...
> SORRY BUT THAT WAS THE LAST DROP IN THE POOL (NOT THE GLASS).
> NO MORE PATIENCE TO THE TMW NOTION OF BACK/FORTH COMPATIBILITY
>
> I'M REALLY, BUT REALLY, PISSED OFF WITH TWM NOTION OF BACKWARD COMPATIBILITY
>
> I ALSO REMOVED ALL MY CONTRIBUTIONS FROM THE FEX

That seems rather extreme. If that's the last drop, do you mind if I ask what the earlier drops were?

Ken

I am also concerned with the lack of compatability of matlab with dlls, matlab is not known for its speed for simulation so why not let us use matlab for what it is good at, building applications, but leave us to decide if we use fortran or C for our dlls and heavy duty crunching needs. alternatively we go back to the core languages. one needs to know thier limits and matlab is moving into to shaking territory

mark

"Kenneth Eaton" <Kenneth.dot.Eaton@cchmc.dot.org> wrote in message <gflj2m$f4h$1@fred.mathworks.com>...
> "Joaquim Luis" <jluis@--ualg--.pt> wrote in message <gflcij$3rm$1@fred.mathworks.com>...
> > SORRY BUT THAT WAS THE LAST DROP IN THE POOL (NOT THE GLASS).
> > NO MORE PATIENCE TO THE TMW NOTION OF BACK/FORTH COMPATIBILITY
> >
> > I'M REALLY, BUT REALLY, PISSED OFF WITH TWM NOTION OF BACKWARD COMPATIBILITY
> >
> > I ALSO REMOVED ALL MY CONTRIBUTIONS FROM THE FEX
>
> That seems rather extreme. If that's the last drop, do you mind if I ask what the earlier drops were?

Another big drop: the removal of the Compiler

MATLAB is not moving in that direction. Mex files are still supported. As
far as I know, capabilities along these lines have only been *increasing*.
However, now the mex file must be compiled for the right target system.
E.g., for execution in a 32bit windows environment, it should be .mexw32,
which is now the default for the mex command when run on a 32bit windows
platform.
--
Mike

"Mark" <mark.e.eigenraam@dse.vic.gov.au> wrote in message
news:gfm2c2$37h$1@fred.mathworks.com...
>I am also concerned with the lack of compatability of matlab with dlls,
>matlab is not known for its speed for simulation so why not let us use
>matlab for what it is good at, building applications, but leave us to
>decide if we use fortran or C for our dlls and heavy duty crunching needs.
>alternatively we go back to the core languages. one needs to know thier
>limits and matlab is moving into to shaking territory
>
> mark

On Nov 14, 7:36=A0pm, "Joaquim Luis" <jl...@--ualg--.pt> wrote:
> I have a many-many-MANY months*hours working time soft that works up till=
 R2008a.
> Now R2008b simply says things like this
>
> Warning: Calling MEX-file 'C:\SVN\mironeWC\lib_mex\set_gmt.dll'.
> MEX-files with .dll extensions will not execute in a future version of MA=
TLAB.
> Warning: Calling MEX-file 'C:\SVN\mironeWC\mexnc.dll'.
> MEX-files with .dll extensions will not execute in a future version of MA=
TLAB.
>
> and the program doesn't work anymore (no more or less, it just crashes).
> No future, just right now.
>
> ARE DLLs DEMONIC?
>
> SORRY BUT THAT WAS THE LAST DROP IN THE POOL (NOT THE GLASS).
> NO MORE PATIENCE TO THE TMW NOTION OF BACK/FORTH COMPATIBILITY
>
> I'M REALLY, BUT REALLY, PISSED OFF WITH TWM NOTION OF BACKWARD COMPATIBIL=
ITY
>
> I ALSO REMOVED ALL MY CONTRIBUTIONS FROM THE FEX
>
> Joaquim Luis

AFAIK there is no difference between a .dll and a .mexw32, you can
rename your dlls to mexw32 and have them work. So the extension is not
the cause of your code crashing.

That being said, it is still very silly of TMW to issue that warning
over a file naming convention! I'm still using R2007b but it'd be very
annoying if I started seeing that warning every time I tried to load a
dll in a future version. Wonder if it does that even for dlls that do
not export the mexFunction interface i.e. dlls that are not mex files?

sounds like there is hope, it is about time TMW spent some time letting us know what they are up too and we can plan for it. if it is a naming convention, one can live with that rather than the (rather arrogant) error message without any further info,
thanks to all for comments

Praetorian <ashish.sadanandan@gmail.com> wrote in message <d1e62298-ffa0-446d-> Joaquim Luis
>
> AFAIK there is no difference between a .dll and a .mexw32, you can
> rename your dlls to mexw32 and have them work. So the extension is not
> the cause of your code crashing.

Yes, you are right. Is not the extension that causes the problem. And, btw, one of the mex that crashes is mexnc, the port to the netCDF library. Another one that cessed working is a interface to the GDAL ibrary. Just "minor" things.
 
> That being said, it is still very silly of TMW to issue that warning
> over a file naming convention! I'm still using R2007b but it'd be very
> annoying if I started seeing that warning every time I tried to load a
> dll in a future version. Wonder if it does that even for dlls that do
> not export the mexFunction interface i.e. dlls that are not mex files?

It is still a naming convention but TMW intend to make it real. See
http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/rn/rn_intro.html
(burried in Version Compatibility Considerations ==> External Interfaces)

namelly:

"Do Not Use DLL File Extensions for MEX-Files

In the future, on 32-bit Microsoft Windows systems, MATLAB will not support MEX-files with a .dll file extension. In MATLAB Version 7.7 (R2008b), if you run a MEX-file with a .dll file extension, MATLAB displays a warning."

"Joaquim Luis" <jluis@--ualg--.pt> wrote in message
news:gflcij$3rm$1@fred.mathworks.com...
>I have a many-many-MANY months*hours working time soft that works up till
>R2008a.
> Now R2008b simply says things like this
>
> Warning: Calling MEX-file 'C:\SVN\mironeWC\lib_mex\set_gmt.dll'.
> MEX-files with .dll extensions will not execute in a future version of
> MATLAB.
> Warning: Calling MEX-file 'C:\SVN\mironeWC\mexnc.dll'.
> MEX-files with .dll extensions will not execute in a future version of
> MATLAB.
>
> and the program doesn't work anymore (no more or less, it just crashes).
> No future, just right now.

The _warning_ (not error) is informing you about a behavior that we plan to
take in the future.

http://www.mathworks.com/access/helpdesk/help/techdoc/rn/broifyr-1.html

There shouldn't, as far as I'm aware, be any change in behavior right now.
If code that used to work is now crashing, there's a bug somewhere, and you
should contact Technical Support so they can help investigate and report the
problem to development to be fixed.

> ARE DLLs DEMONIC?

I don't know exactly why this change is being made, but if I had to guess
it's just the next step on the deprecation process for the .dll extension, a
process that has been in motion for a number of releases.

Back when Windows MEX-files were given the extension dll, we only supported,
well at that point probably 16-bit Windows (3.1? 95?). [That was probably
significantly before my time at The MathWorks.] We weren't in the situation
we are now, where we support both 32-bit and 64-bit Windows. When we
introduced 64-bit Windows, we introduced two new extensions: .mexw64 for
64-bit Windows MEX-files and .mexw32 for 32-bit Windows MEX-files. This was
back in Release 14 with Service Pack 3 in 2005, as the Release Notes
indicate:

http://www.mathworks.com/access/helpdesk/help/techdoc/rn/f26-998197.html

Now that users have had three years to adjust to the new extensions, we're
taking the next step on the deprecation path for the .dll extension. I'm
not certain, but simply changing the extension from .dll to .mexw32 may
work; I haven't tested it.

> SORRY BUT THAT WAS THE LAST DROP IN THE POOL (NOT THE GLASS).
> NO MORE PATIENCE TO THE TMW NOTION OF BACK/FORTH COMPATIBILITY

Believe me when I say that backwards compatibility is very important to us.
I participate in a fair share of meetings discussing new features, and
whenever anyone in the room raises a concern that the new feature is
backwards incompatible, we have a serious discussion about whether or not
that's true, and if it is whether the "pain" caused by the incompatibility
is worth it. Often it is, but sometimes it's not, and we have made changes
to features because of those discussions. I tend to raise those concerns
relatively often, given my background (entering our development organization
from our technical support group) and my exposure to users on CSSM.

> I'M REALLY, BUT REALLY, PISSED OFF WITH TWM NOTION OF BACKWARD
> COMPATIBILITY

If you feel that strongly about this change, contact Technical Support.
While it's rare, we have changed our decision on whether or not to make an
incompatible change like this in the past due to user feedback, particularly
if you have a compelling reason why we should change our decision.

> I ALSO REMOVED ALL MY CONTRIBUTIONS FROM THE FEX

I'm sorry to hear that, but that's your choice.

As a side note, it looks from the name of the file that you're working with
that you're using netCDF files. If so, you may be interested to learn that
we've introduced support for that file format as part of MATLAB itself in
Release R2008b:

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/brrbr9v-1.html

--
Steve Lord
slord@mathworks.com

"Praetorian" <ashish.sadanandan@gmail.com> wrote in message
news:d1e62298-ffa0-446d-bd51-78932c271033@z28g2000prd.googlegroups.com...

*snip*

> That being said, it is still very silly of TMW to issue that warning
> over a file naming convention! I'm still using R2007b but it'd be very
> annoying if I started seeing that warning every time I tried to load a
> dll in a future version. Wonder if it does that even for dlls that do
> not export the mexFunction interface i.e. dlls that are not mex files?

As far as I know, you can't directly invoke DLLs (or files with a MEXEXT
extension) at the command prompt unless they have the mexFunction interface.
I'm not sure if the generic shared library interface (LOADLIBRARY) only
accepts those libraries with the appropriate platform-specific shared
library extension or if you can specify a different extension.

--
Steve Lord
slord@mathworks.com

On Nov 16, 9:23=A0pm, "Steven Lord" <sl...@mathworks.com> wrote:
> "Praetorian" <ashish.sadanan...@gmail.com> wrote in message
>
> news:d1e62298-ffa0-446d-bd51-78932c271033@z28g2000prd.googlegroups.com...
>
> *snip*
>
> > That being said, it is still very silly of TMW to issue that warning
> > over a file naming convention! I'm still using R2007b but it'd be very
> > annoying if I started seeing that warning every time I tried to load a
> > dll in a future version. Wonder if it does that even for dlls that do
> > not export the mexFunction interface i.e. dlls that are not mex files?
>
> As far as I know, you can't directly invoke DLLs (or files with a MEXEXT
> extension) at the command prompt unless they have the mexFunction interfa=
ce.
> I'm not sure if the generic shared library interface (LOADLIBRARY) only
> accepts those libraries with the appropriate platform-specific shared
> library extension or if you can specify a different extension.
>
> --
> Steve Lord
> sl...@mathworks.com

Steve,
You're right, only DLLs exporting the mexFunction interface can be
called from the Matlab command line; and I've never tried calling a
DLL with a different extension using LoadLibrary but I'm willing to
bet that it'll work. I'm sure DLLs have other ways of identifying
themselves and the functions that they export than by just the
extension.

This is exactly what makes this decision by the Mathworks to generate
the warning so bewildering. Matlab can never ever completely stop
supporting the DLL extension in a Windows environment. Matlab loads
several standard Windows DLLs (from the system32 directory for
instance) when it wakes up. Is the Mathworks going to insist that
Microsoft change their naming convention too match their own?

I have no doubt that the Mathworks takes backwards compatibility
seriously but this particular decision seems to have been rather
narrow minded; or maybe we're just not seeing the purpose behind this.
Simply stating that Matlab will stop supporting DLLs in a future
version only manages to annoy your users. And what about 3rd party
toolbox vendors? I know of at least one such vendor that goes through
a lot of trouble to still support Matlab6p5p1. 6p5p1 probably won't
recognize mexw32 files it sees on the path.

Sometimes there is no option but to stop supporting certain things as
you keep updating your product but that is justified only when doing
so provides great advantages to your users. In this case, just
insisting that everyone change their file name extensions, isn't
providing anyone with any advantage, these files are still DLLs,
whether you call them .mexw32 or .monkey!

Ashish.

No, this only applies to mex files, and the only issue is whether MATLAB
even considers the possibility that foo.dll might be a mex file when you
type "foo" at the command line or in an M file. Currently it does, but in
future it will not. It has no implications to the use of dll's for any
other purpose. For example, you can have a mex file that loads any dll's it
needs, no problem.
--
Mike

"Praetorian" <ashish.sadanandan@gmail.com> wrote in message
news:9edd631a-9cfe-4f66-8bf7-358f62773b69@o40g2000prn.googlegroups.com...
Is the Mathworks going to insist that
Microsoft change their naming convention too match their own?

Michael Hosea wrote:
> No, this only applies to mex files, and the only issue is whether MATLAB
> even considers the possibility that foo.dll might be a mex file when you
> type "foo" at the command line or in an M file. Currently it does, but in
> future it will not. ...

What I fail to see is why there need be any reason to quit recognizing
the .dll even if want to somehow make a unique distinction for 64-bit
vis a vis 32-bit mex files.

So what if it's still named foo.dll--what's wrong w/ that?

--

Dpb,



Great question. I think you are getting the root issue in this thread.



I am one of the people who has been part of making this decision and
implementing it.



Two of the initial reasons we "demoted" ".dll" to a secondary MEX extension
on Windows 32 are:

1) There were recurring complaints from customers that NON-MEX DLLs shadowed
M-files with the same name. These NON-MEX DLLs were on the MATLAB path and
were being used as non-MEX libraries. When the users tried to call their
M-files with the same name, MATLAB would dispatch to the ".dll" thinking it
was a MEX-file (which have higher precedence). This issue needed to be
fixed. We considered other ways to make the dispatcher differentiate
non-MEX DLLs and MEX DLLs, but we found that the performance cost was
debilitating.

2) With the introduction of Windows 64, we wanted to differentiate between
the two types of DLLs. We needed to avoid this architecture
incompatibility.



To address issue (1) and for consistency in issue (2) we introduced the MEX
extension ".mexw32" for Windows 32. For backwards compatibility we left
".dll" as a secondary MEX extension. We felt that leaving this
functionality for a few years and slowly phasing it out was a soft rasition
for users.




The main reason we have slowly moved to removing the use of the DLL
extension is that in order to continue innovating we are always looking for
ways to improve our code base. We carefully balance performance
improvements and features with quality and compatibility. In this case we
feel we can simplify our infrastructure by removing this functionality.
Since we strongly encourage users to rebuild their MEX-files every release,
we believe that by now ".dll" MEX-files are starting to become obsolete. We
have been thoughtful and careful about this process. We have also attempted
to be transparent. We have been warning about this transition for several
years and are now approaching the final stages.




I hope this explanation clarifies why we have gone down this path.



If you have further concerns, please report them to our support department.
They will capture your feedback and help us find a way to improve this
situation and other issues like this in the future.

http://www.mathworks.com/support/contact_us/index.html



Thanks,

Gadi

Gadi Reinhorn wrote:
...
> To address issue (1) and for consistency in issue (2) we introduced the MEX
> extension ".mexw32" for Windows 32. For backwards compatibility we left
> ".dll" as a secondary MEX extension. We felt that leaving this
> functionality for a few years and slowly phasing it out was a soft rasition
> for users.
>
> The main reason we have slowly moved to removing the use of the DLL
> extension is that in order to continue innovating we are always looking for
> ways to improve our code base. We carefully balance performance
> improvements and features with quality and compatibility. In this case we
> feel we can simplify our infrastructure by removing this functionality.
> Since we strongly encourage users to rebuild their MEX-files every release,
> we believe that by now ".dll" MEX-files are starting to become obsolete. We
> have been thoughtful and careful about this process. We have also attempted
> to be transparent. We have been warning about this transition for several
> years and are now approaching the final stages.
>
> I hope this explanation clarifies why we have gone down this path.
...

In part, yes.

1) is result of namespace pollution that's a major weakness of the ML
design. I don't see much way at this late date to solve it and suspect
it is only going to continue to get worse as more and more functionality
is added.

2) is, of course, the dilemma of any upgrade path that has compatibility
issues. I'd only note as a rough comparison the path Fortran has taken
of deprecation/obsolescence followed by removal from the Standard at a
later revision is the same general philosophy.

However, the significant difference is that the Fortran Standard is an
independent document and there are multiple implementors/implementations
of the Standard for end users to choose from. It is up to the compiler
vendor to decide when (and whether) to actually remove functionality or
not. Most have not done so except for some very arcane features that
are simply totally incompatible w/ newer, more popular features or a new
compiler entirely that did not exist prior to a more recent Standard.
This path leaves the end user w/ much more flexibility in choosing
precisely how going forward suits their own operation than does the
single-vendor choice.

It would take far more inside information than I have access to (and
more time than I have to devote to the issue even if I had access) to
make a full argument; I only note here the comparative paths for
consideration.

--

"Gadi Reinhorn" <greinhor@mathworks.com> wrote in message <gfv5cl$cas$1@fred.mathworks.com>...
>
> Great question. I think you are getting the root issue in this thread.

>
> Two of the initial reasons we "demoted" ".dll" to a secondary MEX extension
> on Windows 32 are:
>
> 1) There were recurring complaints from customers that NON-MEX DLLs shadowed
> M-files with the same name. These NON-MEX DLLs were on the MATLAB path and
> were being used as non-MEX libraries. When the users tried to call their
> M-files with the same name, MATLAB would dispatch to the ".dll" thinking it
> was a MEX-file (which have higher precedence). This issue needed to be
> fixed. We considered other ways to make the dispatcher differentiate
> non-MEX DLLs and MEX DLLs, but we found that the performance cost was
> debilitating.
>
> 2) With the introduction of Windows 64, we wanted to differentiate between
> the two types of DLLs. We needed to avoid this architecture
> incompatibility.

Hi,

Since you guys continue to ignore what seams to be a minor issue to TMW let me recall it
because I believe it makes a lot of sense to other people.

Q - And what happens if the users does not have a very recent version of
  the Matlab + Compiler to rebuild the MEXs?

A - Easy, you would say, by a new one.

That is, IMHO, the root issue

J. Luis

On Nov 18, 4:33=A0pm, "Joaquim Luis" <jl...@--ualg--.pt> wrote:
> "Gadi Reinhorn" <grein...@mathworks.com> wrote in message <gfv5cl$ca...@f=
red.mathworks.com>...
>
> > Great question. =A0I think you are getting the root issue in this threa=
d.
>
> > Two of the initial reasons we "demoted" ".dll" to a secondary MEX exten=
sion
> > on Windows 32 are:
>
> > 1) There were recurring complaints from customers that NON-MEX DLLs sha=
dowed
> > M-files with the same name. =A0These NON-MEX DLLs were on the MATLAB pa=
th and
> > were being used as non-MEX libraries. =A0When the users tried to call t=
heir
> > M-files with the same name, MATLAB would dispatch to the ".dll" thinkin=
g it
> > was a MEX-file (which have higher precedence). =A0This issue needed to =
be
> > fixed. =A0We considered other ways to make the dispatcher differentiate
> > non-MEX DLLs and MEX DLLs, but we found that the performance cost was
> > debilitating.
>
> > 2) With the introduction of Windows 64, we wanted to differentiate betw=
een
> > the two types of DLLs. =A0We needed to avoid this architecture
> > incompatibility.
>
> Hi,
>
> Since you guys continue to ignore what seams to be a minor issue to TMW l=
et me recall it
> because I believe it makes a lot of sense to other people.
>
> Q - And what happens if the users does not have a very recent version of
> =A0 =A0 =A0 =A0 the Matlab + Compiler to rebuild the MEXs?
>
> A - Easy, you would say, by a new one.
>
> That is, IMHO, the root issue
>
> J. Luis

I agree with Joaquim, in my opinion the issue of M file names clashing
with DLL names is much easier to avoid than having to recompile your
sources. For instance, I use the PLECS toolbox but I don't have a
service contract with them anymore. Their entire interface is through
a single MEX file with a .dll extension. So my options are to renew
the service contract or give up on upgrading Matlab. Most likely it is
going to be the latter. The Mathworks shouldn't be deprecating
functionality unless it adds significant value to the product and with
this particular decision I just fail to see what has been gained.

Ashish.

Praetorian wrote:
...
> I agree with Joaquim, in my opinion the issue of M file names clashing
> with DLL names is much easier to avoid than having to recompile your
> sources. For instance, I use the PLECS toolbox but I don't have a
> service contract with them anymore. Their entire interface is through
> a single MEX file with a .dll extension. So my options are to renew
> the service contract or give up on upgrading Matlab. Most likely it is
> going to be the latter. The Mathworks shouldn't be deprecating
> functionality unless it adds significant value to the product and with
> this particular decision I just fail to see what has been gained.

As I noted, w/o additional input from the TMW decision process, I'd
agree w/ the first statement as being fundamentally true.

I'd recommend strongly those w/ specific difficulties such as you
outline follow up w/ the contact to TMW technical support per Gadi's
suggestion upthread. Whether it'll make any difference or not is
unknowable, of course, but certainly if folks potentially affected don't
make wishes known TMW will continue on the current path.

I've already retired and ceased upgrading ML ages ago so can only talk
from the sidelines but I can surely foresee problems in this route for many.

--

Praetorian wrote:
...
> ... The Mathworks shouldn't be deprecating
> functionality unless it adds significant value to the product and with
> this particular decision I just fail to see what has been gained.

"Deprecating" alone wouldn't be a problem until the version in which the
functionality is actually removed, of course. I could see the
obsolescent warning but seems to me any relatively early removal would
be premature.

BTW, I'm presuming you don't have R2008b that seems to create the
warning so a test of whether simply renaming the .dll file is sufficient?

_IF_ (the proverbial "big if") TMW weren't to break it so thoroughly
that that failed to work, it _might_ be livable although undoubtedly
terribly inconvenient.

--

> Hi,
>
> Since you guys continue to ignore what seams to be a minor issue to TMW let me recall it
> because I believe it makes a lot of sense to other people.
>
> Q - And what happens if the users does not have a very recent version of
> the Matlab + Compiler to rebuild the MEXs?
>
> A - Easy, you would say, by a new one.
>
> That is, IMHO, the root issue
>
> J. Luis

This whole discussion is silly. Just rename your .dll to .mexw32 and you're good to go. No new products, no new contracts, no dollars spent, and no rebuilding mex files.

On Oct 12, 1:07 pm, "Sank " <s...@spu.edu> wrote:
> > Hi,
>
> > Since you guys continue to ignore what seams to be a minor issue to TMW let me recall it
> > because I believe it makes a lot of sense to other people.
>
> > Q - And what happens if the users does not have a very recent version of
> >    the Matlab + Compiler to rebuild the MEXs?
>
> > A - Easy, you would say, by a new one.
>
> > That is, IMHO, the root issue
>
> > J. Luis
>
> This whole discussion is silly.  Just rename your .dll to .mexw32 and you're good to go.  No new products, no new contracts, no dollars spent, and no rebuilding mex files.

And regurgitating 3-year old threads, just to tell people they're
silly is even sillier.

"TideMan" <mulgor@gmail.com> wrote in message
news:3a415543-0687-42c4-9606-020cc79aefb1@s5g2000pra.googlegroups.com...
> On Oct 12, 1:07 pm, "Sank " <s...@spu.edu> wrote:
>> > Hi,
>>
>> > Since you guys continue to ignore what seams to be a minor issue to TMW
>> > let me recall it
>> > because I believe it makes a lot of sense to other people.
>>
>> > Q - And what happens if the users does not have a very recent version
>> > of
>> > the Matlab + Compiler to rebuild the MEXs?
>>
>> > A - Easy, you would say, by a new one.
>>
>> > That is, IMHO, the root issue
>>
>> > J. Luis
>>
>> This whole discussion is silly. Just rename your .dll to .mexw32 and
>> you're good to go. No new products, no new contracts, no dollars spent,
>> and no rebuilding mex files.
>
> And regurgitating 3-year old threads, just to tell people they're
> silly is even sillier.

Since this thread was raised from the dead, I'd like to point one thing out
that didn't get answered in the original thread (mainly because it was
brought up near the end) but was quoted in Sank's response.

You don't need MATLAB Compiler to build or rebuild MEX-files. You just need
_a_ compiler for the language in which the MEX-file was written.

For C/C++ MEX-files in the current release R2011b, Microsoft Visual C++ 2010
Express on Windows and gcc/g++ on Linux are both freely available and listed
on the Supported Compilers page. I'm not certain about Xcode on OS X;
according to Apple's Xcode page, Xcode 4.1 is available for Lion for free
but if you're on Snow Leopard you may have to be in Apple's developer
program or pay for Xcode 4.0 or 3.2. I'm also not certain about Fortran
compilers on Windows; Linux and OS X both have gfortran listed as freely
available.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 10/12/2011 9:13 AM, Steven_Lord wrote:
...

> ... I'm also not
> certain about Fortran compilers on Windows; Linux and OS X both have
> gfortran listed as freely available.

There are gfortran and g95 (altho seems to be mostly moribund lately)
that are F90/95+ as well as Silverfrost FTN95

Other commercial options exist including Intel and NAG as well...

The older F77 options are still around and are used by quite a sizable
number altho I'd recommend going w/ F95+ capable for anything other than
legacy code that has some _real_ reason for using a particular compiler
since very little that is F77-compatible is likely to not be easily
convertible to F90+; only much older code or that which used specific
extensions is generally problematic in that regard.

--

I don't disagree. But your premise is off. It was not to tell people they're silly, it was to provide a solution to a problem that had unclear closure. I don't get this in a mailing list, this thread is visible to all google searchers, and they (as well as I) benefit from having solutions posted, no matter the age of the thread.

Cheers,

TideMan <mulgor@gmail.com> wrote in message <3a415543-0687-42c4-9606->
> And regurgitating 3-year old threads, just to tell people they're
> silly is even sillier.