- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a problem that I think is basically to do with incompatabilities between different versions of the Intel MKL. I was hoping someone could offer some advice. I'm afraid it's a bit complicated, and involves interactions between multiple products, so getting support is difficult, as it's not clear who's "to blame".
I have written a number of "mex" files in Matlab. For those that don't know these are dynamically linked libraries that allow Fortran and C code using a particular API to appear as native Matlab functions. I have written them in C (compiled with MS VC 7.1) and in Fortran (compiled with IVF 9.0). I have used these mex files successfully for a number of years (the latest edit date on the source code was in December 2001).
The problems I have been having coincided with an upgrade of Matlab to the latest version and an upgrade of Windows (to XP SP2). These required rebuilding the mex files against a new set of libraries.
These mex files call functions in a NAG Fortran Library DLL (Mark 20). This library itself is bundled with MKL_LAPACK64.DLL and LIBGUIDE40.DLL. The documentation from NAG suggests these come from MKL v5.1.
I can show with a stand-alone program (not a mex file), which calls the NAG library function, that I can't replace the v5.1 MKL DLLs with the DLLs with the same filenames that come with MKL v9.0.
This is a problem because the latest version of Matlab (R2007a) itself uses MKL v9.0 and, in particular, loads LIBGUIDE40.DLL on startup. If I let Matlab use the v9.0 MKL DLL then the mex file doesn't work (i.e. internally in Matlab a call to LoadLibraryEx fails). Initial experiments suggest that if I get rid of the v9.0 LIBGUIDE40.DLL from the path, then Matlab can use the v5.1 version and the mex function works correctly. But I'm nervous doing this.
Any suggestions? What is LIBGUIDE40.DLL? Why can't the v5.1 MKL_LAPACK64.DLL use the v9.0 LIBGUIDE40.DLL?
Is there any way that I can use the two different versions of the LIBGUIDE40.DLL in the same process. For instance could I patch the v5.1 MKL_LAPACK64.DLL to depend on, say, LIBGUIDE40_51.DLL? Unfortunately, I'm a computational scientist, not a Windows programming expert.
This has taken days to track down. I wouldn't have managed without Dependancy Walker!
Andrew
I have written a number of "mex" files in Matlab. For those that don't know these are dynamically linked libraries that allow Fortran and C code using a particular API to appear as native Matlab functions. I have written them in C (compiled with MS VC 7.1) and in Fortran (compiled with IVF 9.0). I have used these mex files successfully for a number of years (the latest edit date on the source code was in December 2001).
The problems I have been having coincided with an upgrade of Matlab to the latest version and an upgrade of Windows (to XP SP2). These required rebuilding the mex files against a new set of libraries.
These mex files call functions in a NAG Fortran Library DLL (Mark 20). This library itself is bundled with MKL_LAPACK64.DLL and LIBGUIDE40.DLL. The documentation from NAG suggests these come from MKL v5.1.
I can show with a stand-alone program (not a mex file), which calls the NAG library function, that I can't replace the v5.1 MKL DLLs with the DLLs with the same filenames that come with MKL v9.0.
This is a problem because the latest version of Matlab (R2007a) itself uses MKL v9.0 and, in particular, loads LIBGUIDE40.DLL on startup. If I let Matlab use the v9.0 MKL DLL then the mex file doesn't work (i.e. internally in Matlab a call to LoadLibraryEx fails). Initial experiments suggest that if I get rid of the v9.0 LIBGUIDE40.DLL from the path, then Matlab can use the v5.1 version and the mex function works correctly. But I'm nervous doing this.
Any suggestions? What is LIBGUIDE40.DLL? Why can't the v5.1 MKL_LAPACK64.DLL use the v9.0 LIBGUIDE40.DLL?
Is there any way that I can use the two different versions of the LIBGUIDE40.DLL in the same process. For instance could I patch the v5.1 MKL_LAPACK64.DLL to depend on, say, LIBGUIDE40_51.DLL? Unfortunately, I'm a computational scientist, not a Windows programming expert.
This has taken days to track down. I wouldn't have managed without Dependancy Walker!
Andrew
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The documentation says that libguide versions should be upward compatible, but only among versions compatible with Intel Fortran 8.0 or later. Libguide is the Intel OpenMP library. That is, you should be able to use the most recent libguide required by any of your objects.
There is little chance of making stuff built for compilers prior to Intel Fortran 8.0 work with recent MKL, if they refer to the earlier Fortran run-time libraries. Doesn't Matlab provide any guidance about which compilers are compatible?
You would have to prevent use of threading, to avoid the requirement for libguide. For example, you might SET MKL_SERIAL Then, possibly, you might avoid conflicts over threading libraries, at the expence of potential performance.
There is little chance of making stuff built for compilers prior to Intel Fortran 8.0 work with recent MKL, if they refer to the earlier Fortran run-time libraries. Doesn't Matlab provide any guidance about which compilers are compatible?
You would have to prevent use of threading, to avoid the requirement for libguide. For example, you might SET MKL_SERIAL Then, possibly, you might avoid conflicts over threading libraries, at the expence of potential performance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I have a workaround.
I used a binary editor to replace the single occurrence of the string "LIBGUIDE40" with "LIBGUIDE4Q" in the v5.1 MKL_LAPACK64.DLL. I renamed the v5.1 version of LIBGUIDE40.DLL to LIBGUIDE4Q.DLL and also replaced the single occurrenace of the string "LIBGUIDE40" with "LIBGUIDE4Q" in the same file.
This means that the process can use both versions of LIBGUIDE40.DLL simultaneously as they now have different names.
Inital test suggest everything is now working!
If anyone can think of any potential problems, I'd be interested in hearing about them.
I used a binary editor to replace the single occurrence of the string "LIBGUIDE40" with "LIBGUIDE4Q" in the v5.1 MKL_LAPACK64.DLL. I renamed the v5.1 version of LIBGUIDE40.DLL to LIBGUIDE4Q.DLL and also replaced the single occurrenace of the string "LIBGUIDE40" with "LIBGUIDE4Q" in the same file.
This means that the process can use both versions of LIBGUIDE40.DLL simultaneously as they now have different names.
Inital test suggest everything is now working!
If anyone can think of any potential problems, I'd be interested in hearing about them.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page