PS: Be aware, it seems that email manager has "eaten" some character such as "F" in -Wl,-L"c:/Program iles" - should be -Wl,-L"c:/Program Files" Best regards George ----- Original Message ----- From: "G. Perendia" <george@perendia.orangehome.co.uk> To: "List for Dynare developers" <dev@dynare.org> Sent: Thursday, September 18, 2008 11:54 AM Subject: Re: [DynareDev] Dynare++ k-order-perturbation design Hi I still owe you this: The following SINGLE command line illustration COMPILES AND LINKS fs2000a_dynamic.c in Windows DOS command console window using MingW gcc (and threads):
gcc -DMATLAB_MEX_FILE -mthreads -DPOSIX_THREADS -shared
-I"c:/Program Files"/MATLAB_SV71/extern/include -ofs2000a_dynamic.dll fs2000a_dynamic.c < any other &&&.c or local ????.a files and then other lib params...> -Wl,-L"c:/Program iles"/MATLAB_SV71/extern/lib/win32/microsoft/ -Wl,-llibmex -Wl,-llibmx -Wl,-L"f:/CygWin/usr/local/atlas/lib" -Wl,-llapack -Wl,-lcblas -Wl,-lf77bla s -Wl,-latlas -lg2c -lmingw32 -lstdc++ -Wl,-L"f:/Pthreads/Pre-built.2/lib" -W l,-lpthreadGC2 Of ocurse, this has much more (unused) libraries than needed for fs2000a_dynamic.c but they are there for illustration (and it also works too) The above command links to the "NATIVE" lapack and cblas libraries but similarly, MATLAB mwlapack may be placed there instead as: -Wl,-llibmwlapack -Wl,-llibdflapack MinGW ld by default exports all symbols so that both mxFunction() can be called by MATLAB and the Dynamic() function should be callable directly by other C/C++ applications or another DLL (but that bit I have not managed to test yet). As mentioned, the output <*>.dll may be renamed to <*>.mexw32 (or similar) and it works too. Best regards George ----- Original Message ----- From: "Michel Juillard" <michel.juillard@ens.fr> To: "List for Dynare developers" <dev@dynare.org> Sent: Friday, September 12, 2008 5:00 PM Subject: Re: [DynareDev] Dynare++ k-order-perturbation design Hi George, I think that you are on the right track
1) Calling <model>_dynamic: there is a mex function mexCallMATLAB() which can call either internal MATLAB functions, .m files and/or, as well, other MEX files, whatever it finds appropriate. Thus, we may be able to call <model>_dynamic mex/dll as currently created by Dynare preporcessor directly from the new mex/dll file This option allows calls to <mod>_dynamic irrespective whether it is, or is not compiled as a mex function.
Although we should be able to improve performance, cut out the MATLAB intermediary overhead and use native .dll (.so) - thought that not tested yet - I suggest the mexCallMATLAB become implemented as a backup alternative used when if mex/dll is not compiled.
SURE
2) "mex" compilation (i.e. "to mex or not to mex?"): On my Windows platform and with Matlab v.7.1., compiling & linking <a>.C files (containing mexFunction and linking the mex libs) as DLLs with either MSVC or minGW directly creates a DLL which can be called either with extension .DLL, or simply renamed as <a>.mexXX (e.g. changing extension from .DLL to .mexw32 on Win 32bit platform).
Thus, it seems that this direct approach does not require use of mex command (or the mexopts.bat),and, I wander if anyone tested if this approach works on Linux too(?). For time being I intend to use it at least for the prototyping in Windows (i.e. considering that n-order is not expected to be re-compiled on-the-go for the start at least).
Should be even easier in Linux. Please, tell us exactly which steps (and compiler/linker switches) you use to create a DLL( mexxxx) directly.
3) Re. MATLAB LAPACK: Thanks for the suggestion to use it too but now I need to resolve some other issues. I.e., Due to MATLAB lapack idiosyncrasies:
a) MathWorks' mwlapack.lib in earlier versions was containing both lapack and blas, but it has later been split into two libraries: mwlapack.lib - without blas - and the blas.lib - this creating some though small, linking problems,
This is the main reason why we have to maintain to separate sets of DLLss for older and for newer versions of Matlab
b) lapack functions in windows not having "_" suffix but having it on the Linux platforms!?(%$£"@*), - i.e., this creating some more linking problems and poss some additional changes to the code to allow for the conditional compilation (i.e. some is already present in dynare++ and the current Dynare sylv mex source)
I think that there is no escape to testing for an environment variable saying if you are in Windows or not and having a macro setting the necessary completion of the function name depending on the environment.
c) apparently, according to MathWorks documentation, on windows, their mwlapack is supported only for MSVC (and I could not get it to link
properly
with minGW but poss. due to different reasons) !? (ditto.).
Again, as we may not be recompiling n-order on the fly, for a time being it seems that it may be simpler to use minGW and the "native" lapack and atlas libraries for generating n-order .DLL rather than Matlab's LAPACK- again, at least for prototyping and poss. its first release?!.
Mathworks doesn't support gcc in the Windows envrionment, but I was able to link gcc compiled code with their libraries for MSVC.
4) Regarding mxMalloc - Michel was right - it is recommended for all malloc calls within mex files so that Matlab can ensure freeing memory when mex call is finished, but it is not obligatory and, probably not necessary when if the C/C++ code carefully deletes all allocated memory itself (which seems to be the case with both Dynare++ k-order-perturbation and the Markov Switching code but should be checked but I will double check it.)
OK, if there is memory problem, Matlab most likely aborts abruptly. All the best, Michel
Please do let me know your thoughts.
Best regards
George
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev _______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev