- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I recently migrated to the latest VS and Intel fortran compiler. I am getting the following errors:
Severity Code Description Project File Line Suppression State
Error error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj) libcpmtd.lib(locale.obj)
Any advice on overcoming this would be greatly appreciated.
Many thanks,
ACAR
Link Copied
- « Previous
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have no objection whatsoever to sending my code to someone at Intel (apart from the mild embarrassment I will have in an expert viewing the code of a mechanical engineer). Before I do this though I will take Steve's suggestion and look deeper into the .obj files to see if this brings up the solution. I'll report back in due course.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This isn't something appropriate for Intel support. You have all the tools at hand necessary to determine the cause and fix the problem. It isn't a shortcoming in the Intel product. Searching the .obj files (and .lib files) for the offending library name will get you 90% of the way there.
I also want to elaborate on my earlier remarks regarding debug libraries. There's nothing wrong with using debug libraries while building debug configurations, but it can get messy if you are pulling in static libraries you didn't build. One big advantage of the debug libraries, that I alluded to before, is that the C library's get/free adds consistency checks with the debug library that can help you locate heap corruption, double frees, etc.
I will also point out that the debug libraries are NOT redistributable, so you can't (or shouldn't) build an application linked to the debug libraries and then run it on a system where the development product is not installed. This is especially noticeable if you are linking to debug DLL libraries.
Intel Fortran, unlike the various C/C++ compilers (Intel and MS), doesn't generate different code depending on your choice of libraries. This is why it is often a good idea to build Fortran static libraries with the "Disable OBJCOMMENT directives" option enabled so that the objects in the library don't request any particular set of libraries. This does mean that the executable project must pull in the necessary libraries, and if it's not a Fortran main program you have to manually name the needed Fortran run-time libraries when linking.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have taken Steve's suggestion from the following topic:
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/520311
This seems to have removed all the conflicts and I now get an executable for my solution but it does not 'execute'!
Any suggestions regarding this - I've attached the buildlog?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please describe exactly how you attempted to "execute" and what you observed after that. Did you see any error messages? Did the program hang (check with the Task Manager or the tasklist command line utility).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I double click the executable and absolutely nothing happens - no error messages, no hanging (no evidence of the process in the Task Manager).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The program does run in debug mode - bizarre!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Run the program from a command prompt window and see if you get any messages.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Absolutely nothing when I attempt to run the program from the command prompt...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does this program look for input files and exit if it doesn't find any?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope, as noted earlier it works perfectly well when run in debug mode. It is an analysis program which throws up a dialog requesting the user to select either an existing database file or create a new one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suppose the next step is to look at the Windows error log to see if it shows an application error for this program. In the Windows search box, type "error log" and click on View error logs. Select Windows Logs > Applications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error log shows:
EFESYS.exe - System Error |
The program can't start because mkl_rt.dll is missing from your computer. Try reinstalling the program to fix this problem. |
I did need to add mkl_rt.lib to get my application to link. But I have not requested mkl_rt.dll in the linker so I don't know where it is getting this idea from. Anyway, the application works in debug mode although it might be the case that when I ran it I didn't use the parts of the program that used the mkl libraries.
Anyway, when I search for mkl_rt.dll there are several instances found so the error is not actually true.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One doesn't link to DLLs, you link to the export library. By default, the folders containing MKL's DLLs aren't added to PATH - you must do that yourself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
True. I've added the following path in the linker:
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\redist\ia32_win\mkl
Same problem exists...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DLLs are located and loaded when your program is run, not by the linker. The directory containing the DLL should be added to your PATH.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks IanH. That has solved the problem.
Okay chaps I would like to thank you all for your patience and persistence in helping me through this issue. I seem to now have a viable project with which to move forward in my R&D. Software development is very much a part-time activity for me and whilst I am quite adept at developing viable and efficient fortran code I do struggle with the issues we have had to deal with in this post, i.e., making the correct settings in VS. I guess if I did more software development I would get used to dealing with these issues but as I rarely have to make changes I tend to forget how to do it. Anyway, a useful and successful exercise and, again, many thanks for your assistance.
BTW, I am very pleased with the gift from Intel for becoming a Brown Belt developer :)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
- Next »