- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
Just wasted a day looking for a bug in my code only to find that it was due to the Composer-XE install adding the redist folder to my path. This caused my 32-bit linked custom dll to use the wrong versions of the Intel libraries (libmmd.dll, libiomp5md.dll and libifcoremd.dll) and generate incorrect results. After much testing I got the right set of libraries into the right place and my dll now returns the correct values again. Interestingly the 32 bit Composer-XE versions of the dll's give different answers while the older 11.1.060 versionsgive the right answers, so I'm really confused about what is going on.
My questions are:
1. Can I remove the Composer additions to the path to get my system back to the way it was before so that my installed programs and development environment (VB6)load the correct dll's and give the correct answers?
2. Is there a way that I can force the dll build process to load the correct versions into my custom dll so that mismatches between versions can be avoided, especially on client machines.
3. How can I find out which dll's are being loaded by my application? It loads my dll at run-time and the system (Windows Vista 64), presumably thenloads the dependant dll's. My recollection of the process isthat itchecks the application folder first and thensearchesthe path to locate the required dll's. As I did nothave the 11.1.060 versions in my application folder or path, the load process found thetheXE versions and these gave the wrong answers.I fixed the problem by copying the 11.1.060 versions directly into my application folder.
4. Is it possible thatthe load process might have grabbed the 64 bit versions of the dll's? I may be wrong about this as the XE 32 bitdll's are also in the path, but later in the search order. However, when I added the32 bit XE dll's to my application folder, it gave different answers to thethe two casesreferred to in Q3, and the answers were better (about the right order of magnitude), but still not correct.
5. It really worries me that I get the right answers using the 11.1.060 dll's, but not with the new XE versions (either by default search or by deliberate copying to the application folder). I spent a lot of time developing my custom dll to use multiple cores and it works really well and I have validated the results that it generates. So to have the answers change simply by installing theComposer-XE environment is frightening to say the least. I have recompiled my dll using theComposer XE 2011 environment, but it gives the wrong answers when using the XE dll's and the right answers with the 11.1.060 dll's.
Needless to say, the code is non-trivial and the above symptoms may indicate that there is a bug in my program. However, I really don't know how to even startfinding the problem.
Thanks in advance,
John Paine
Just wasted a day looking for a bug in my code only to find that it was due to the Composer-XE install adding the redist folder to my path. This caused my 32-bit linked custom dll to use the wrong versions of the Intel libraries (libmmd.dll, libiomp5md.dll and libifcoremd.dll) and generate incorrect results. After much testing I got the right set of libraries into the right place and my dll now returns the correct values again. Interestingly the 32 bit Composer-XE versions of the dll's give different answers while the older 11.1.060 versionsgive the right answers, so I'm really confused about what is going on.
My questions are:
1. Can I remove the Composer additions to the path to get my system back to the way it was before so that my installed programs and development environment (VB6)load the correct dll's and give the correct answers?
2. Is there a way that I can force the dll build process to load the correct versions into my custom dll so that mismatches between versions can be avoided, especially on client machines.
3. How can I find out which dll's are being loaded by my application? It loads my dll at run-time and the system (Windows Vista 64), presumably thenloads the dependant dll's. My recollection of the process isthat itchecks the application folder first and thensearchesthe path to locate the required dll's. As I did nothave the 11.1.060 versions in my application folder or path, the load process found thetheXE versions and these gave the wrong answers.I fixed the problem by copying the 11.1.060 versions directly into my application folder.
4. Is it possible thatthe load process might have grabbed the 64 bit versions of the dll's? I may be wrong about this as the XE 32 bitdll's are also in the path, but later in the search order. However, when I added the32 bit XE dll's to my application folder, it gave different answers to thethe two casesreferred to in Q3, and the answers were better (about the right order of magnitude), but still not correct.
5. It really worries me that I get the right answers using the 11.1.060 dll's, but not with the new XE versions (either by default search or by deliberate copying to the application folder). I spent a lot of time developing my custom dll to use multiple cores and it works really well and I have validated the results that it generates. So to have the answers change simply by installing theComposer-XE environment is frightening to say the least. I have recompiled my dll using theComposer XE 2011 environment, but it gives the wrong answers when using the XE dll's and the right answers with the 11.1.060 dll's.
Needless to say, the code is non-trivial and the above symptoms may indicate that there is a bug in my program. However, I really don't know how to even startfinding the problem.
Thanks in advance,
John Paine
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Yes, as a workaround you can remove Composer XE folders from the system path. You canalternatively use environment batch files provided together with 11.1 to set the environment to this version. You can invoke them using shortcuts in Start Menu or by launching them directly:
"C:\Program Files\Intel\Compiler\11.1\060\Bin\iclvars.bat" arch [vs]
arch is the architecture (ia32, ia32_intel64, intel64, ia32_ia64 or ia64). vs is optional parameter and can be one of vs2008 or vs2005 (specification of Microsoft Visual Studio to use).
Yes, as a workaround you can remove Composer XE folders from the system path. You canalternatively use environment batch files provided together with 11.1 to set the environment to this version. You can invoke them using shortcuts in Start Menu or by launching them directly:
"C:\Program Files\Intel\Compiler\11.1\060\Bin\iclvars.bat" arch [vs]
arch is the architecture (ia32, ia32_intel64, intel64, ia32_ia64 or ia64). vs is optional parameter and can be one of vs2008 or vs2005 (specification of Microsoft Visual Studio to use).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the information. I will delete the redist folders from my path so I can have some confidence that I'm picking up the correct libraries for my applications. Thanks also for the information on the environment batch file, but this isn't very useful in the context of my development environment as I'm developing multiple 32bit and 64bit applications using a variety of languages.
Interestingly I tried replicating the results from yesterday and nowall of the options are returning the same correct answers. I haven't rebooted or changed the path, buttheold 11.1, the new XE32 dll's in the application folder andthe default dll's loaded from the path all give the same answers. Very strange.
Best regards
John
Thanks for the information. I will delete the redist folders from my path so I can have some confidence that I'm picking up the correct libraries for my applications. Thanks also for the information on the environment batch file, but this isn't very useful in the context of my development environment as I'm developing multiple 32bit and 64bit applications using a variety of languages.
Interestingly I tried replicating the results from yesterday and nowall of the options are returning the same correct answers. I haven't rebooted or changed the path, buttheold 11.1, the new XE32 dll's in the application folder andthe default dll's loaded from the path all give the same answers. Very strange.
Best regards
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I have revisited this problem to try to establish what is going on as one of my clients is having problems running my program on his machine. The results on my machine are correct and the valuse generated on his machine are not.
After much hacking of the PATH to remove the folders that the Composer install so kindly added, and after many runs and system sleuthing to determine just which Intel dll's are being loaded, I have worked out that the program works fine if I use just the 32 bit11.1.60 versions of the following dll's:
libmmd.dll
After much hacking of the PATH to remove the folders that the Composer install so kindly added, and after many runs and system sleuthing to determine just which Intel dll's are being loaded, I have worked out that the program works fine if I use just the 32 bit11.1.60 versions of the following dll's:
libmmd.dll
libifcoremd.dll
libiomp5md.dll
butthe program generates incorrect values if I use the Composer XE versions of the dll's.
Through a process of elimination, I found that if I replace the Composer XE version of libmmd.dll with the 11.1.60 version, the program works correctly.
As there are no other changes to the program environment (same exe, same custom dll's, same path), I would say that this indicates that there's a problem with the libmmd.dll that is causing the program to not work correctly.
I have yet to hear back from the client on the results of testing the program with this specific set of dll's, but I have my fingers crossed.
So is this a bug in libmmd.dll or something different in the XE environment that is causing the problem? Either way, how canI work out how to find the bug (if it is mine) or how to prove that the problem is in libmmd.dll (and therefore Intel's bug)?
Best regards
John
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