I installed parallel Studio 2018, update 3, and it gave me the VS 2013 shell, which I used
to run this simple program. However, it still found a missing entry point, although it DID
try to use the MKL library.
Obviously, something is wrong with the way the LINKER is used here.
So what is this entry point it could not find ? I dont know the purpose of this. Does anyone ?
BTW, I tried all 3 choices for the QMKL choice, as to which MKL libary to attach.
But none of them worked - I got a missing entry point for all 3 choices.
see screen shot.
Your code calls DGESV with incorrect arguments. As you can see from the documentation, https://software.intel.com/en-us/mkl-developer-reference-fortran-gesv#5C18C896-C835-402E-AE63-BA7C98..., DGESV takes 8 arguments. All these arguments must be present, in the order documented, and input arguments must contain correct values.
If you wish to call the Lapack95 generic routine GESV, which takes 2 to 4 arguments, you have follow the rules laid out at https://software.intel.com/en-us/mkl-developer-reference-fortran-fortran-95-interface-conventions-fo....
Several of the arguments to DGESV are input arguments, and they must be set to correct values. Your code does not do this.
When you write code that does not conform to the language rules, the consequences may be confusing and unpredictable. You may see compile time errors, linker errors, run time errors, garbage results, etc. It is usually not worth one's time to probe these unwanted consequences in detail.
It does not work, even with the correct number and types of arguments.
see attached scrreen shot
I also tried SGESV as well with real*4 arguments, same screwed up result.
I used the VS2013 shell, hoping the Fortran interface wouldn't be broken there.
Could there be some interaction with windows 10? I need someone who can get on my computer
with a (paid) help call, maybe they will have some ideas. Otherwise this is a lot of GUESSING.
Do you have paid telephone assistance anywhere ?
BTW, I am not concerned at this point what numbers are actually being input to the matrices.
I am just trying to get the LINK to the MKL to work like it is supposed to.
If the number and types of arguments DONT MATCH, you usually get some kind of compile/build error message, right ?
at least with user written code, maybe its different with library routines.
Interestingly enough, when I use VS2010 the link works fine, no problems.
I cant use VS2017, because the Fortran source code interface is broken.
I guess no one there has a clue whats going on ?
Can I escalate this to an expert ?
Your problem is not in linking, it's in running the program. Unlike the Fortran run-time DLLs, the MKL DLLs are not added to PATH by the Parallel Studio install. You have to do that yourself, but for some unfathomable reason, the MKL documentation never mentions this.
You can either identify the folder containing the MKL DLLs and add it to the system PATH environment variable, or link to the static library form of MKL. Please ask in the MKL forum for help with this as it has zero to do with Fortran.
OK, I will do that - but I was told that using that linker option would be all that is needed. (QMKL: ) etc.
That is where you tell it to use the MKL library, right ? (parallel, sequential, etc.)
and it still does NOT explain why I dont see that problem with VS2010 - Is that because it is from Microsoft ?
I already mentioned this in the MKL forum, but no response so far.
/QMKL tells the compiler and linker that you want to link to a particular set of MKL libraries. But if it links to the DLL libraries, you still need to have the DLLs on PATH in order to run the program. The Intel "Performance Libraries" don't add themselves to PATH during installation - something I think was a wrong decision, but I was unable to convince anyone on the team of that.
My guess is that it "worked" in VS2010 because that older version of Parallel Studio selected the static libraries rather than the DLL libraries.
Hi Steve -
I did some further investigation, and found out that it was
POINTING TO THE RIGHT LIBRARY,
and the linker does not give any errors re missing entry points.
It only finds the missing entry point when I EXECUTE the program. Have you heard of this before ?
Wouldn't you think the missing entry point would be detected during the LINKER phase first ?
The reason I think it was pointing to the right library is that it CAN FIND the routines I am trying to use.
That missing entry point is something no one has yet explained - - not even in at the MKL forum.
Is there a way to get paid telephone consultation ?
Bill, you're not listening to what I am telling you. But I'll back up a bit.
When a program links to a shared (DLL) library, it links against an "export library" (.LIB) that maps entry points to a particular named DLL. When you run the EXE, Windows looks through its search list for the first same-architecture DLL of the name that was specified in the export library. It then looks in the DLL to find each entry point referenced.
(At least) two things can go wrong here. 1) The DLL is simply not found. You'll get a clear message about this. 2) The DLL Windows finds isn't one that is compatible with the export library seen by the linker. The usual error you'll get in this case is that some particular entry point is not found, which is what you are seeing.
In MOST cases, the reason for this is that Windows found an older DLL in its search path. But it's also possible that Windows found a newer version that happens to omit the entry point you used. The words I have for developers who do this aren't printable in a family forum, but I'm sad to say that the MKL project has a history of breaking changes and removing interfaces. I don't know if that's what's going on here.
Windows looks for DLLs in the following places (in order):
This sounds like an error-prone process, and it is - a popular term for this is "DLL Hell". Many years ago, Microsoft came up with a new scheme called "side-by-side (SxS) assemblies". DLLs linked to that use "SxS" don't just have a DLL name, but additional information including a specific version. These DLLs are installed in a special folder tree and DLLs referenced this way bypass the search list and are found in the SxS folder tree. Microsoft began using this for its own Visual Studio DLLs back in the VS2005 timeframe.
I always thought that this was a good idea, and Iobbied the Intel libraries teams to adopt it, but supposedly one of the folk who talk to Microsoft got warned away from it, with the hint that something better was coming. It never came.
I wrote earlier that the MKL DLLs aren't added to PATH by the PSXE install. Part of the reason for this is that there is a limit to the size of the PATH environment variable, somewhere around 2000 characters. If you exceed this, Windows breaks very badly and not in an obvious way. The folder paths Intel uses were long, and both 32-bit and 64-bit folders needed to be added to PATH, so one "solution" was to put the compiler DLLs in PATH but not the performance libraries. This could have been solved by putting ALL of the Intel developer tool DLLs in a single folder (or two, one for each platform), but the performance library teams didn't like that idea. One rationale I heard was that some customers like to point to a particular version of the library.
So, what can you do? I looked more closely at the error message you received and I see that Windows is finding mkl_sequential.dll in the PSXE 2018 install folder. This is not unreasonable. I do note with interest that the entry point name shown in the message omits the leading underscore that I would expect to see in a 32-bit routine name. Why that should be, I don't know.
I will download and install MKL and see if I can learn anything more about the particular routine identified. I am NOT an MKL expert and will approach this only from my generic background of understanding DLLs.
I installed the current MKL and the copy of mkl_sequential.dll it installed (in the path cited in your error message) has the correct entry point mkl_blas_cgem2vc (without the leading underscore.)
At this point I'll ask you to take this to the MKL forum, or file a support ticket (probably the better bet.)
I do not know the specific versions of the MKL DLLs on Billsincl's PC, and even if I did it is unlikely that I would have the same versions on my PC.
However, I note the following details from two versions of the MKL DLLs that I have on my PC.
The 32-bit versions of the 2018.0.3 MKL DLLs export the following symbols:
CGEM2VC _CGEM2VC@56 _cgem2vc@56 _cgem2vc_@56 _mkl_blas__cgem2vc@56 cgem2vc cgem2vc_ mkl_blas__cgem2vc
The corresponding DLLs from the 2015 edition of Parallel Studio (MKL version 11.02.02) do not export the two symbols in the above list that contain the prefix "_mkl_blas_".
As Steve has explained, if I linked an EXE with the 2018 MKL libraries but it so happens that the 2015 DLLs appear first in the DLL search path chain, I should see the same error as Billsincl.
I don't know how many versions of MKL are installed on Billsincl's PC. Perhaps, for him, the simplest solution is to uninstall all but the latest version, unless he needs and has installed more than one version with some definite purpose.
I would be happy to reinstall the latest version of MKL, but I have to make sure I am getting the 64 bit version, since the machine is a 64 bit CPU. I was wondering - rather than going thru "DLL hell," is there a way to copy the needed relocatable binary (compiled) of the routine I wanna use ? I only care about one entry point. So why not compile the source code of the routine and chunk it in with all the other routines ? That way I completely avoid the LINKER problem. That is assuming the MKL guys will give me that source code. Of course I could write my own source code to solve the A*X=B matrix equation. That might be less agony than this linker issue which no one so far has been able to really address. as far as I can deetermine, the actuall binaries are not readily available, just the entire library, and that is where these problems occur. Does anyone have any idea what this missing entry point actually does ?
I was wondering if the version of PARALLEL STUDIO I am using has to be paired with a particular version of the MKL.I have installed.
That would of course create a giant pitfall that anyone could walk into.
And would also explain the problem I am having.
as far as I can tell, no one has given us any guidance about that particular issue.
Was it considered not important enough to bother with ?
I would be happy to reinstall the latest version of MKL, but I have to make sure I am getting the 64 bit version, since the machine is a 64 bit CPU.
No, you can use the 32-bit or the 64-bit version of MKL on Windows-64. In fact, your screenshots in #1 indicate that you built your EXE for 32-bit, since is the error message is about one of the 32-bit MKL DLLs.
The Parallel Studio installer lets you choose how much of MKL (none, 32-bit only, 64-bit, etc.) to install. Separate installers for MKL are also available, and the release notes of each version of MKL tell you which compiler versions are compatible.
I only care about one entry point. So why not compile the source code of the routine and chunk it in with all the other routines ?
You may care about only one MKL routine, but that one routine may have calls to other MKL routines, etc. I just checked, and I find that your short program needs 75 entry points from the MKL library. Do you really want to obtain, compile and link all those routines?
You can obtain the source codes for BLAS and Lapack at www.netlib.org/lapack, but I do not think that you should take that route. You can obtain pre-built Lapack for Windows from https://icl.cs.utk.edu/lapack-for-windows/lapack/ . This is an older version of Lapack, and will be slower performing than the one in MKL, but it may turn out to be adequate for your needs, at least in the beginning.
It appears that I have the 2016 version of the MKL libary, and am currently using the VS2010 for the IDE.
But what is weird is, two identical source codes under that give different outcomes.
One of them runs when I say "start debugging," and the other one crashes with that mysterious missing entry point. CGEN2SVU.
But when I look at the BUILDLOG for the one that crashes, it does not say anything about the missing entry point.
I am attaching the BUILDLOG so you can see what it does. Everything looks peachy keeny until I say Start Debugging.
Even when it attaches the right library, i still get that stupid error message.
What is the purpose of that entry point ?
anyway, this is the buildlog,
The build log shows that you have Parallel Studio 2016, and VS is using it to build your program. The linker links your OBJ file (the one produced by compiling your Fortran source file) to one of the MKL import libraries from MKL 11.3.4 (which came with Parallel Studio 2016). When the program is run, however, the program loader finds an older version of the MKL DLL, instead of the matching DLL of the import library that the linker used. This older library does not contain one or more of the required entry points.
I ran a test to verify the explanation just given. I compiled a modified version of your program using PS2016 and MKL 11.3.4. I then ran the EXE from a PS2013-SP1 command window. I received an error pop-up that said that the entry mkl_serv_print_verbose_info could not be located in the EXE. Except for the name of the missing entry, this is exactly the same as what you have been describing.
To make further progress, we need to know which versions of Parallel Studio/Fortran Composer/Intel Fortran you have, and may have had earlier, on your PC. I also need to know the environment on your PC (i.e., the output of the SET command, or the expansion of %PATH%, at least), and the contents of the source file Console2_main.f90 that you used in #17 and #18.
I will be glad to give you that, except that i do not how to get that info (in some cases).
That is why a remote assist would be the most helpful, if anyone even does that any longer.
So how do I get those version IDs ?
I could send a screen shot, if you will tell me where to look.
The build log of #21 lists the source file name as linsol_main.f90, for which you have not shown the source. If its contents are identical to those of console2_main.f90, please state so.
Similarly, I need to see your environment data. Without these piece of information, it is not possible to attempt diagnosing the problem.
You may obtain a list of all the software installed on your PC using the command
wmic /output:InstallList.txt product get name,version
For more details and alternative methods, please see, for example, https://www.makeuseof.com/tag/list-installed-programs-windows/ .
Similarly, the command
set > bsenv.txt
will save the environment to a file. You can view the two files InstallList.txt and bsenv.txt with Notepad. The first of these will be a Unicode text file. Please zip up to two files and attach the zip file to your reply. Alternatively, you can save their contents as .ODT files and attach the latter.