Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28451 Discussions

Program compiles then doesn't compile

sindizzy
Novice
2,545 Views

So I am trying to update an F90 program from Intel Parallel Studio XE 2011 to VS 2022 with Intel oneAPI. The solution is made up of 6 projects.

Right off the bat the compilation works which is great.

Build started...
1>------ Build started: Project: ZZZ(IFORT), Configuration: Release Win32 ------
1>Compiling with Intel® Fortran Compiler Classic 2021.5.0 [IA-32]...
1>Linking...
1>ZZZ- 0 error(s), 1 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Now I close the solution, go get a beer and come back to work on it again. So I open the solution and for every open tab I get this message

sindizzy_0-1644114248808.png

 

I close all the open tabs in VS and compile again. Now I get this error:

libmmt.lib(log10_iface_c99.obj) : error LNK2005: __CIlog10 already defined in libucrt.lib(log10_impl.obj)
Creating library C:\ZZZ.lib and object C:\ZZZ.exp
C:\ZZZ.EXE : fatal error LNK1169: one or more multiply defined symbols found


ZZZ- 2 error(s), 1 warning(s)

No code changes. Nope. Nada. Zero. Nil.
No config changes. Nope. Nada. Zero. Nil.

Just a successful compile, close solution, re-open solution unsuccessful compile.

What am I not doing right???

 

 

 

 

 

0 Kudos
32 Replies
andrew_4619
Honored Contributor II
847 Views

It seems to me looking at your link fragment you are doing a static build but some of your libraries were built for dynamic (DLL) linking. 

0 Kudos
sindizzy
Novice
842 Views

Ok can you explain to me what that is? I am a seasoned developer but most of my experience has been with plain jane F77 code. He does have a bunch of LIB resource files. Is that what you are referring to? I am also familiar with DLLs of the COM and .NET world.

 

Also, just starting to create the new solution from scratch He has this option which is not the default. The default activates Check Routine Interfaces, which I assume checks that routines and their calls match up. If I leave it at default it does break at one spot. There must have been a reason he turned that off but he has been gone for at least a year from our group. However, it has been compiling at every run now so it appears that we may be on to something.

 

sindizzy_0-1644193522086.png

 

0 Kudos
sindizzy
Novice
838 Views

From what I am reading the LIB files are static libraries and are bound at compile time. If that is true then is it safe to assume that the code in these LIB files gets baked into the final EXE so you don't need to provide the LIB files to the end user? Looking at how he was deploying the software to the group I dont see any LIB files so I think that kind of makes sense.

0 Kudos
IanH
Honored Contributor II
831 Views

I have seen cases where the generated interfaces confuse the build system (but relevant for re-compiling excessively, not linking).  Not sure if those cases are still relevant with current releases of the compiler.  I have also seen cases (again - historic, may not be relevant with current releases) where interface checking came up with false positives (noting that the number of times I've found a real false positive is about the same as the number of times that I thought I had a false positive, but was wrong...).  But either way, having to turn that diagnostic off unless I fully understood why I needed to turn it off, would terrify me.

0 Kudos
sindizzy
Novice
831 Views

But you are right the EXEs do interact with some DLLs and those are deployed to the end user. I assume those are bound at runtime of the EXE.

0 Kudos
andrew_4619
Honored Contributor II
817 Views

Well I would have warnings setting on and fix what gets thrown up. You can have mismatched interfaces that are not standard conforming  where it will still work OK by luck or by compiler extension (non-standard) behaviour.  A common one is passing a scaler into an array or visa versa. If it is confusing post some code snippets for the errors. Someone will help.

 

Are all your libraries Fortran or are some from other languages? The linking/binding options for all the items need to be consistent/compatible.

So in Fortran this setting:

andrew_4619_0-1644231981004.png

But in C: this setting needs to be looked at...

 

andrew_4619_1-1644232175087.png

 

0 Kudos
sindizzy
Novice
803 Views

All the LIBs and DLLs that it interacts with are Fortran based. I would further say that they are all based on F77 but the compiler could be different. But I will check out those settings.

0 Kudos
andrew_4619
Honored Contributor II
793 Views

OK up thread you have now added new information. You have third part libraries all build by different vendors with different compilers some of which are very old.  That is a problem.  You need to acquire a consistent and compatible set of libraries  and you need to compile and link with a compatible compiler.  That might be a challenge.

 

0 Kudos
sindizzy
Novice
786 Views

Only one vendor using F77 spec but possibly using different compilers. We are only one of many companies that received these LIBs and DLLs so we can't just ask for new files under one compiler. The vendor has many clients which they have to support, so changing any of that process would take years.

 

But, just as an fyi, we successfully have been using Intel Parallel Studio XE 2011 with no issues. That may be hindsight since now this is a new Intel compiler. But that still doesn't answer the question as to why with oneAPI it compiles fine. Then close and re-open and it no longer compiles. With no code or config changes.

 

I've also posted the log file where it fails. I assume it's a math library and the same function exists in two places ???

 

1> Searching C:\Program Files (x86)\Intel\oneAPI\compiler\2022.0.0\windows\compiler\lib\ia32_win\libmmt.lib:
1> Found _log10
1> Referenced in libbsm_bcslib.lib(hdpitg.obj)
1> Referenced in libbsm_bcslib.lib(hdgedi.obj)
1> Loaded libmmt.lib(log10_iface_c99.obj)
1>libmmt.lib(log10_iface_c99.obj) : error LNK2005: __CIlog10 already defined in libucrt.lib(log10_impl.obj)

0 Kudos
sindizzy
Novice
746 Views

Ok folks I took everything I learned in this thread and applied it to my situation at work.

I decided to bite the bullet and thus created a solution and projects from scratch. Using VS2022 and the Intel oneAPI, I created 6 individual QuickWin projects with all configs at default. I added the F90 code files and LIBs. Compiled and no errors whatsoever.

I tested by various combinations of viewing some F90 files in the IDE, building, cleaning, re-building, closing VS, re-opening the solution, etc. No changes in code or config on any of the projects. It compiled every time without errors (except a couple of times where it said the manifest could not be embedded in the EXE, but I blame that on the malware scanner on our network which locks the EXE while scanning).

Next for me is the following:

1. Review the config options in the prior projects and try to understand why they were setup that way. I saw some options which didn't quite make sense to me and will have to do some research.

2. Run a big batch of data through the old EXEs and new EXEs and determine if there are any differences. I think this would be a good approach to validating the new solution. Also will review processing times between the two runs.

Anything else I should consider?

Many thanks for all the help.

 

 

0 Kudos
JohnNichols
Valued Contributor III
731 Views

@sindizzy  noted that validating the new solution against the old.

 

Q1 Was the old one tested against known solutions or experimental data -- if not then it is not a good solution.  

 

 

0 Kudos
sindizzy
Novice
722 Views

Yes, the old EXE's were compared against known solutions and validated.

0 Kudos
Reply