Dave, thanks for the bug report. I've updloaded a new version 2.0.2
that should fix the problem (moving __stdcall after the return type as
you suggest). Please let me know if there are any other problems
under Windows, as I don't use Windows myself (I cross-compile the DLL
file from GNU/Linux).
(If someone could try compiling the Python and/or Matlab plugins under
Windows, that would be helpful too.)
Steven
On Jun 17, 2010, at 2:16 AM, Dave Katz wrote:
It seems there is a minor problem with nlopt.h in 2.0.1 under visual
studio. I
upgraded to 2.0.1 today and tried to compile some code which was
previously
compiling with nlopt-1.2 and got a bunch of errors. It appears to be
a header
file problem with nlopt.h so I had a look at it and the problem
appears to be
caused by the NLOPT_STDCALL macro and how it is defined. From
Microsoft's
language reference (http://msdn.microsoft.com/en-us/library/zxk0tw93
(VS.80).aspx):
return-type __stdcall function-name[(argument-list)],
however, currently it is used as (in nlopt.h):
NLOPT_EXTERN void __stdcall nlopt_srand(unsigned long seed),
which expands to:
extern __declspec(dllimport) __stdcall void nlopt_srand(unsigned
long seed);
I was able to get my code to compile by moving the __stdcall part
after the
return type. Can I possibly get this problem looked at?
Regards
Dave
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
