Example projects (VS 2010) for custom redist DLL are broken

Example projects (VS 2010) for custom redist DLL are broken

The example projects provided with the MKL to create a customized minimal redist dll have the paths to the included LIB files hardcoded instead of using $(MKLROOT), this means once the projects are copied away from the MKL install directory they fail to build with error "LNK1131: no library file specified".

Removing the .lib file from the project and adding it to the project properties, as well as adding $(MKLROOT)\\lib to the library paths fixes the problem.

5 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.


Currently these MS-projectsfor custom buildercan be used only intheir location and have relative path to lib-directory. We will consider possibilty to use MKLROOT instead but then MKL custom builder has to require correct MKLROOT vallue (setting MKL environment via mklvars)

-- Victor

Alright, I mainly wanted to mention this because it took a bit of time figuring out what was breaking and this way others might see this when searching for the compile error.

Thanks Henrik. By the way, could you share with us some information about using this projects:
- are they useful at all in comparison with command line interfcae of custom builder
- what is to be added in MKL custom builder from your point of view
- any suggestions/comments

-- Victor

I'll be honest, I used the projects because I found the documentation for those first while searching for a way to reduce the redist footprint. Using the command line interface probably would have been easier, by just making a new dedicated makefile project which calls it - the key point was, I needed some sort of VS wrapper around the creation of the dedicated DLL because our build server uses msbuild, and I did not want to add special casing on the build server side of things. Perhaps the three subprojects could be replaced with a single makefile project?
I also ended up merging the 32 and 64 bit versions of the i_malloc_dll and vml_dll_core projects, we use the same solution for 32/64 bit builds.
It would be nice if the MKL plugin for the VS project configuration could have an additional option, "use custom DLL", because right now I have to disable the use of MKL in the plugin and manually add the include paths to the project, otherwise I think the MKL default libs have priority.

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen