Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
30 Views

error LNK2005 Fortran/C++

Hello,

I have a Visual Studio Solution which should create a DLL. It consists of a Fortran part and a part written in C++ in two seperate projects. The Fortran Source Code is calling C++ functions. When I try to build it, I get the following message:

error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)

From my understanding this means that the powf is defined more than one time, therefore it is not clear which function really should be called.

Some more information:

- When I build it on "Release" it works.

- I was reading that this error can be cause of different floating point models. So I made sure that those models are set to the same option in every project (Fortran and C++). https://software.intel.com/en-us/forums/intel-c-compiler/topic/622985

- In the C++-projects I included the librarys <cmath> or <math.h> but got the same error on both includes.

- Both are built with the same Runtime Library. Tried out a couple of possible combinations too.

 

I would be glad for any help

0 Kudos
13 Replies
Highlighted
Black Belt
30 Views

Please provide the complete

Please provide the complete transcript of the attempted linking step. Around the single line that you showed, there would have been a few lines that showed the source of the other location(s) of the previously defined symbol, such as another library name.

Once that information becomes available, one would have to look at the full linking command line, or the selected options in VS for the project. If you are able to provide the build log, that would help, too.

0 Kudos
Highlighted
Beginner
30 Views

Copied from the buildlog.htm

Copied from the buildlog.htm and identical to the output in visual studio:

Druckzyklen.lib(Main_Berechnung.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
Druckzyklen.lib(Main_Berechnung.obj) : error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)
Druckzyklen.lib(factor_correct.obj) : error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)
   Creating library d:\Development\E2\E2_DLL\Debug\E2_0306.lib and object d:\Development\E2\E2_DLL\Debug\E2_0306.exp
Debug\E2_0306.dll : fatal error LNK1169: one or more multiply defined symbols found

 

0 Kudos
Highlighted
Black Belt
30 Views

You have shown the output

You have shown the output only, not the commands used for the build. Zip the buildlog.htm and attach it here. We'd also need to see the C++ project settings.

Perhaps try this - set the Fortran project property Fortran > Libraries > Use Runtime Library to "Multithread DLL" (for the Release configuration) or "Multithread Debug DLL" for the Debug configration.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
30 Views

The buildlog is attached to

The buildlog is attached to this mail.

The list of properties is very long, are there settings that are particularly important?

I already tried it out to change the runtime librarys, without any success.

0 Kudos
Highlighted
Black Belt
30 Views

You are linking in several

You are linking in several libraries, and the run-time library settings in all of them have to match. I see you are already using /libdir:noauto on your own project, which is good. But if the other libraries were built in C++ with conflicting options, that can be a headache.

The first thing I would do is, from a Fortran command prompt, do a "dumpbin -directives" on each of the .lib files to see which libraries they want. You would then set the executable project property Linker > Input > Ignore all default libraries to Yes. Then you'll have to name all of the required libraries (such as libifcoremd) in the Linker > Additional Dependencies property. This will take some effort to sort out.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
30 Views

Thank you so much, now it

Thank you so much, now it works.

But to be honest I haven't carried out all your suggestions from above yet. I started switching the property "Ignore all default libraries" to Yes and tried to compile, and then it works. Although some of the linked projects still have it on "No". So now it is kinda "lucky combination" of the project settings, that works fine in this case.

I want to understand exactly what happens here and tried to do such a dumpbin-directive, but so far I have not figuered it out how to do this. Can you give me an advice? I tried to execute it via the comand line and the ifort.exe, but this did not work.

Thanks a lot in advance.

0 Kudos
Highlighted
Black Belt
30 Views

There is a space before

There is a space before -directives. Looks like this:

D:\Projects>dumpbin -directives t.lib
Microsoft (R) COFF/PE Dumper Version 14.14.26433.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file t.lib

File Type: LIBRARY

   Linker Directives
   -----------------
   -defaultlib:ifconsol
   -defaultlib:libifcoremt
   -defaultlib:libifport
   -defaultlib:libmmt
   -defaultlib:LIBCMT
   -defaultlib:libirc
   -defaultlib:svml_dispmt
   -defaultlib:OLDNAMES

  Summary

          B9 .drectve
          10 .text

By default, when you compile a source the compiler inserts instructions for the linker (directives) that ask the linker to link to a set of libraries (which it then finds through its normal search path). In this example you can see that it wants the static library versions of the Intel Fortran and Microsoft C++ libraries. Your program may not need all the libraries listed.

Now I'll recompile the source and specify /libs:dll (which is the default for new projects in Visual Studio):

Dump of file t.lib

File Type: LIBRARY

   Linker Directives
   -----------------
   -defaultlib:ifconsol
   -defaultlib:libifcoremd
   -defaultlib:libifportmd
   -defaultlib:libmmd
   -defaultlib:MSVCRT
   -defaultlib:libirc
   -defaultlib:svml_dispmd
   -defaultlib:OLDNAMES

  Summary

          BB .drectve
          10 .text

The library names have switched to the DLL versions (mostly). There is a compile option to not add these directives, which is usually a good idea when building a static library. The "Ignore all default libraries" linker option tells the linker to ignore any directives present in the objects.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Valued Contributor III
30 Views

Quote:Alexander W. wrote:

Alexander W. wrote:

.. I haven't carried out all your suggestions from above yet. I started switching the property "Ignore all default libraries" to Yes and tried to compile, and then it works ..

@Alexander W.,

I'm curious about this thread of yours and where the discussion is going.  I ask because I dabble with mixed language projects involving Fortran every now and then and the only time I have encountered the error you indicated in the original post (error LNK2005: _powf already defined in lib..) was when the program main was not Fortran or when C++ DLL was involved and when Intel Fortran version used to compile the code was inconsistent with IFORT_COMPILER[vv] macro used in Visual Studio solution property settings for header files and library directories e.g., using Intel Fortran compiler 18.0 to compile Fortran source and linking to C++ main but with a setting that employs IFORT_COMPILER17; now if the macro is reset to IFORT_COMPILER18, then the link error disappears:

  1. So if your main program is not in Fortran or C++ DLL is involved, can you confirm you are following the instructions on this page?  https://software.intel.com/en-us/articles/configuring-visual-studio-for-mixed-language-applications
  2. Or if your situation is that of a Fortran program calling C++ functions via a link to a static C++ library, can you please look at Quote #6 in this thread https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/699941, ;try out the simple complete solution provided in the Example.zip attachment, and report here if it works?

Thanks,

0 Kudos
Highlighted
Beginner
30 Views

@FortranFan:

@FortranFan:

Thanks for your suggestions. I tried out the possible solutions, but nothing worked. Again for info: I can built a Release-DLL successfully, and in a non-DLL solution I can debug into the C++ project as well, so in principle the inclusion of a C++ project to Fortran works. The only thing that does not work is a debug-DLL.

What I've tried now (according to Steves advices):

I have carried out a dumpbin directive for each of the projects (the ones that build a static library) that are linked in. Then I set the option "Ignore all default libraries" and linked in only the default-libs that are really needed. The same I did for the Main-Project (DLL),  but this did not work! I got 500+ errors "error LNK2019: unresolved external symbol [...]".

When I switch the options back to "Ignore all refault libraries" to "No", I still get the message "error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)".

It's getting really frustrating, but maybe you still have an idea.

0 Kudos
Highlighted
Valued Contributor II
30 Views

To quote #6: "Then you'll

To quote #6: "Then you'll have to name all of the required libraries (such as libifcoremd) in the Linker > Additional Dependencies property. This will take some effort to sort out."

"The same I did for the Main-Project (DLL),  but this did not work! I got 500+ errors "error LNK2019: unresolved external symbol [...]"."

This can surely only because there are required libs that you have not included. 

 

0 Kudos
Highlighted
Valued Contributor III
30 Views

[quote=Alexander W.]

Alexander W. wrote:

..  When I switch the options back to "Ignore all refault libraries" to "No", I still get the message "error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)".

It's getting really frustrating, but maybe you still have an idea.

@Alexander W.,

If you really, really want to resolve your linker error LNK2005 and overcome the ensuing frustration with it, then I'll suggest you provide the details.  I think you have posted verbiage but that's not sufficiently actionable for any readers to give you concrete solutions.

Consider this thread again and specifically Quote #6 in it with a ZIP file attachment: you should be able to put together a small Visual Studio solution example with your Fortran (DLL?) and C++ (static library) projects where all the selections (compiler options, linker options, library specifications, etc.) match your actual solution and project files.  Share such a ZIP attachment containing your solution, project and source files which reproduce the linker error.  Note you can have some simple code, say calculate 3.14 to the power of n (pick some value for n) in C++ and assign the result to some variable in Fortran.  This will help review what is going on and point toward a resolution.

0 Kudos
Highlighted
Beginner
30 Views

I tried to do what you

I tried to do what you advised, and created a new Fortran solution with a linked C++ project, using the same settings and properties as the solution that I'm trying to fix. I couldn't reproduce the error, so I compared every single property and finally got it running:

In my solution I have 7 projects added, 6 Fortran, 1 C++. Now all of the them have Libraries/Run-Time-Library: "Multithreaded DLL" (thus no static linking). Non of the projects ignores all default libraries (so no library is explicitly added or ignored).

Maybe some day this may help somebody who has the same problem.

0 Kudos
Highlighted
Valued Contributor III
30 Views

Quote:Alexander W. wrote:

Alexander W. wrote:

.. Now all of the them have Libraries/Run-Time-Library: "Multithreaded DLL" (thus no static linking). Non of the projects ignores all default libraries (so no library is explicitly added or ignored).

Maybe some day this may help somebody who has the same problem.

"Maybe some day .. somebody who has the same problem." will do better to first refer to Intel documentation, an easy click away: https://software.intel.com/en-us/fortran-compiler-19.0-developer-guide-and-reference-building-intel-...

Intel® Fortran Compiler .. Developer Guide and Reference wrote:

.. You must take care to choose the same type of run-time libraries in both your Fortran and C project. For example, if you select Multithreaded DLL in your Fortran project, you must select Multithreaded DLL in your C project. Otherwise, when your build your mixed Fortran/C application, you will receive errors from the Linker regarding undefined and/or duplicate symbols. ..

0 Kudos