can't link - linker in endless loop

[Brian_Murphy]

This is with visual studio 2019.

All of the sudden a project won't link.  Compiling goes ok, but then linking never ends until I break it.  The output window shows that the first obj file is being linked over and over.  I rebooted and this didn't help.  What happened?

[Steve_Lionel]

Wild a** guess here - you have an antivirus program that decides this newly created executable is malware and deletes it. Meanwhile Visual Studio doesn't find the EXE there and wants to recreate it. Check your AV activity log to see if that's what it is.

[Brian_Murphy]

Antivirus logs are clean.  I recalled a backup, and that is working.  Thank goodness.  Must have been gremlins.

I compared the vfproj files and don't see any obvious clues.

[Steve_Lionel]

Interesting...

[Brian_Murphy]

Below are successful and unsuccessful buildlogs.  Right after the Creating command line line, the unsuccessful one shows repeated runs of ifort.exe.  The successful one doesn't show any lines with ifort.exe.  So maybe that's a hint to what went wrong.  In the output folder of the botched one, no EXE file ever appears while it is executing.  There are a lot of things to like about Visual Studio 2019, but this feature isn't one them.

Successful buildlog.

Linking...
Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"Debug\XLTRC2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\XLTRC2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.pdb" /SUBSYSTEM:CONSOLE /STACK:50000000 /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.lib" mkl_blas95.lib mkl_lapack95.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib libiode_ia32.lib legacy_stdio_definitions.lib -qm32 /qoffload-ldopts="-mkl=sequential" "Debug\Validator.obj" "Debug\Imped.obj" "Debug\Lund_NLCoeff.obj" "Debug\SPLINEFIT.obj" "Debug\BalanceMatrix.obj" "Debug\ProgressIndicator.obj" "Debug\SplineAndSplint.obj" "Debug\DefNLBrgs.obj" "Debug\DebugTools.obj" "Debug\PlotCompEig.obj" "Debug\OrderEig.obj" "Debug\j-t rpoly from blevins.obj" "Debug\Modules.obj" "Debug\mkl_pardiso.obj" "Debug\mylinear_operators.obj" "Debug\CheckLimeKey.obj" "Debug\XLTRC2 interfaces.obj" "Debug\ReduceMat.obj" "Debug\ManeuverLd.obj" "Debug\DCS_Map.obj" "Debug\Arnoldi.obj" "Debug\Transf.obj" "Debug\BendingStress.obj" "Debug\ShaftBow.obj" "Debug\OperT_tx_M_x_T.obj" "Debug\EIG-routines.obj" "Debug\ReCompute.obj" "Debug\Main.obj" "Debug\ConelemTor.obj" "Debug\AdjustLnSpd.obj" "Debug\UTF_Map.obj" "Debug\StatIndet.obj" "Debug\ImbalResp.obj" "Debug\BaseExcitation.obj" "Debug\selmatTor.obj" "Debug\NewmarkBetaWilsonTheta.obj" "Debug\EccDpdBear.obj" "Debug\Ralston.obj" "Debug\Conelem.obj" "Debug\AddStiffDamp.obj" "Debug\UndmpTorCrit.obj" "Debug\Heun.obj" "Debug\selmat.obj" "Debug\DmpCritSpdTF.obj" "Debug\UndmpCrit.obj" "Debug\PartialFractions.obj" "Debug\FixInput.obj" "Debug\AssembleMatTorLat.obj" "Debug\RotatingNS.obj" "Debug\PlotModShp.obj" "Debug\Input.obj" "Debug\Casing.obj" "Debug\UCS_Map.obj" "Debug\SpdDpdBear.obj" "Debug\Outputs.obj" "Debug\FFCritSpd.obj" "Debug\AssembleMatTor.obj" "Debug\RK4.obj" "Debug\AssembleMat.obj" "Debug\TransientAnalysis.obj" "Debug\ImportCasingMat.obj" "Debug\BinIOfile.obj" "Debug\ShowMat.obj" "Debug\FF_Map.obj" "Debug/Script1.res" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Code\TurboActivate.lib" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\DLLUser\Debug\DLLUser.lib" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\UTIL\Debug\UTIL.lib" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\SRC\Debug\SRC.lib"
]
Creating command line "Link @"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\RSP1.rsp""

Embedding manifest...
mt.exe /nologo /outputresource:"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.exe;#1" /manifest "Debug\XLTRC2.exe.intermediate.manifest"
Performing Post-Build Event...
copy "Debug\XLTRC2.exe" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\\XLTRC2\"
        1 file(s) copied.


XLTRC2 - 0 error(s), 0 warning(s)

Here is the one that never stops:

Linking...
Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"Debug\XLTRC2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\XLTRC2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new\Debug\XLTRC2.pdb" /SUBSYSTEM:CONSOLE /STACK:50000000 /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new\Debug\XLTRC2.lib" mkl_blas95.lib mkl_lapack95.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib libiode_ia32.lib legacy_stdio_definitions.lib  -qm32 /qoffload-ldopts="-mkl=sequential" "Debug\Validator.obj" "Debug\OrderEig.obj" "Debug\dlarnv.obj" "Debug\BalanceMatrix.obj" "Debug\SPLINEFIT.obj" "Debug\ProgressIndicator.obj" "Debug\dlaruv.obj" "Debug\DefNLBrgs.obj" "Debug\SplineAndSplint.obj" "Debug\DebugTools.obj" "Debug\PlotCompEig.obj" "Debug\Imped.obj" "Debug\Lund_NLCoeff.obj" "Debug\j-t rpoly from blevins.obj" "Debug\Modules.obj" "Debug\mkl_pardiso.obj" "Debug\CheckLimeKey.obj" "Debug\mylinear_operators.obj" "Debug\XLTRC2 interfaces.obj" "Debug\Heun.obj" "Debug\BaseExcitation.obj" "Debug\StatIndet.obj" "Debug\RK4.obj" "Debug\DmpCritSpdTF.obj" "Debug\Conelem.obj" "Debug\AdjustLnSpd.obj" "Debug\UTF_Map.obj" "Debug\UndmpCrit.obj" "Debug\ShowMat.obj" "Debug\FixInput.obj" "Debug\ReduceMat.obj" "Debug\AddStiffDamp.obj" "Debug\OperT_tx_M_x_T.obj" "Debug\Input.obj" "Debug\UndmpTorCrit.obj" "Debug\UCS_Map.obj" "Debug\ShaftBow.obj" "Debug\FFCritSpd.obj" "Debug\AssembleMatTorLat.obj" "Debug\ReCompute.obj" "Debug\PlotModShp.obj" "Debug\Casing.obj" "Debug\NewmarkBetaWilsonTheta.obj" "Debug\ImportCasingMat.obj" "Debug\selmatTor.obj" "Debug\FF_Map.obj" "Debug\AssembleMatTor.obj" "Debug\SpdDpdBear.obj" "Debug\Ralston.obj" "Debug\ManeuverLd.obj" "Debug\BinIOfile.obj" "Debug\TransientAnalysis.obj" "Debug\selmat.obj" "Debug\EIG-routines.obj" "Debug\DCS_Map.obj" "Debug\AssembleMat.obj" "Debug\PartialFractions.obj" "Debug\Main.obj" "Debug\ImbalResp.obj" "Debug\BendingStress.obj" "Debug\Transf.obj" "Debug\RotatingNS.obj" "Debug\EccDpdBear.obj" "Debug\ConelemTor.obj" "Debug\Arnoldi.obj" "Debug\Outputs.obj" "C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new\Code\TurboActivate.lib"
]
Creating command line "Link @"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new\Debug\RSP1.rsp""


C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new>"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2020.0.166\windows\bin\intel64_ia32\ifort.exe" ".\Release\AddStiffDamp.obj" ".\Release\AdjustLnSpd.obj" ".\Release\Arnoldi.obj" ".\Release\AssembleMat.obj" ".\Release\AssembleMatTor.obj" ".\Release\AssembleMatTorLat.obj" ".\Release\BalanceMatrix.obj" ".\Release\BaseExcitation.obj" ".\Release\BendingStress.obj" ".\Release\BinIOfile.obj" ".\Release\Casing.obj" ".\Release\CheckLimeKey.obj" ".\Release\Conelem.obj" ".\Release\ConelemTor.obj" ".\Release\DCS_Map.obj" ".\Release\DebugTools.obj" ".\Release\DefNLBrgs.obj" ".\Release\DmpCritSpdTF.obj" ".\Release\EccDpdBear.obj" ".\Release\EIG-routines.obj" ".\Release\FF_Map.obj" ".\Release\FFCritSpd.obj" ".\Release\FixInput.obj" ".\Release\Heun.obj" ".\Release\ImbalResp.obj" ".\Release\Imped.obj" ".\Release\ImportCasingMat.obj" ".\Release\Input.obj" ".\Release\j-t rpoly from blevins.obj" ".\Release\Lund_NLCoeff.obj" ".\Release\Main.obj" ".\Release\ManeuverLd.obj" ".\Release\mkl_pardiso.obj" ".\Release\Modules.obj" ".\Release\mylinear_operators.obj" ".\Release\NewmarkBetaWilsonTheta.obj" ".\Release\OperT_tx_M_x_T.obj" ".\Release\OrderEig.obj" ".\Release\Outputs.obj" ".\Release\PartialFractions.obj" ".\Release\PlotCompEig.obj" ".\Release\PlotModShp.obj" ".\Release\ProgressIndicator.obj" ".\Release\Ralston.obj" ".\Release\ReCompute.obj" ".\Release\ReduceMat.obj" ".\Release\RK4.obj" ".\Release\RotatingNS.obj" ".\Release\selmat.obj" ".\Release\selmatTor.obj" ".\Release\ShaftBow.obj" ".\Release\ShowMat.obj" ".\Release\SpdDpdBear.obj" ".\Release\SplineAndSplint.obj" ".\Release\SPLINEFIT.obj" ".\Release\StatIndet.obj" ".\Release\Transf.obj" ".\Release\TransientAnalysis.obj" ".\Release\UCS_Map.obj" ".\Release\UndmpCrit.obj" ".\Release\UndmpTorCrit.obj" ".\Release\UTF_Map.obj" ".\Release\Validator.obj" ".\Release\XLTRC2 interfaces.obj"  
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.


C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new>"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2020.0.166\windows\bin\intel64_ia32\ifort.exe" ".\Release\AddStiffDamp.obj" ".\Release\AdjustLnSpd.obj" ".\Release\Arnoldi.obj" ".\Release\AssembleMat.obj" ".\Release\AssembleMatTor.obj" ".\Release\AssembleMatTorLat.obj" ".\Release\BalanceMatrix.obj" ".\Release\BaseExcitation.obj" ".\Release\BendingStress.obj" ".\Release\BinIOfile.obj" ".\Release\Casing.obj" ".\Release\CheckLimeKey.obj" ".\Release\Conelem.obj" ".\Release\ConelemTor.obj" ".\Release\DCS_Map.obj" ".\Release\DebugTools.obj" ".\Release\DefNLBrgs.obj" ".\Release\DmpCritSpdTF.obj" ".\Release\EccDpdBear.obj" ".\Release\EIG-routines.obj" ".\Release\FF_Map.obj" ".\Release\FFCritSpd.obj" ".\Release\FixInput.obj" ".\Release\Heun.obj" ".\Release\ImbalResp.obj" ".\Release\Imped.obj" ".\Release\ImportCasingMat.obj" ".\Release\Input.obj" ".\Release\j-t rpoly from blevins.obj" ".\Release\Lund_NLCoeff.obj" ".\Release\Main.obj" ".\Release\ManeuverLd.obj" ".\Release\mkl_pardiso.obj" ".\Release\Modules.obj" ".\Release\mylinear_operators.obj" ".\Release\NewmarkBetaWilsonTheta.obj" ".\Release\OperT_tx_M_x_T.obj" ".\Release\OrderEig.obj" ".\Release\Outputs.obj" ".\Release\PartialFractions.obj" ".\Release\PlotCompEig.obj" ".\Release\PlotModShp.obj" ".\Release\ProgressIndicator.obj" ".\Release\Ralston.obj" ".\Release\ReCompute.obj" ".\Release\ReduceMat.obj" ".\Release\RK4.obj" ".\Release\RotatingNS.obj" ".\Release\selmat.obj" ".\Release\selmatTor.obj" ".\Release\ShaftBow.obj" ".\Release\ShowMat.obj" ".\Release\SpdDpdBear.obj" ".\Release\SplineAndSplint.obj" ".\Release\SPLINEFIT.obj" ".\Release\StatIndet.obj" ".\Release\Transf.obj" ".\Release\TransientAnalysis.obj" ".\Release\UCS_Map.obj" ".\Release\UndmpCrit.obj" ".\Release\UndmpTorCrit.obj" ".\Release\UTF_Map.obj" ".\Release\Validator.obj" ".\Release\XLTRC2 interfaces.obj"  
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

and so on...........

[andrew_4619]

that looks like a "always out of date and needs rebuilding" problem. I was once plagued with one of those I think the cause is linked with the dependancy checker in VS having duff data somewhere.

[Brian_Murphy]

That could very well be it.  This project has two other LIB dependencies in other vfproj projects that are managed by visual studio.  This project was building ok until I replaced all the fortran source files in those other projects with new versions and rebuilt those two LIB projects.  Then when I tried to rebuild the main project I started having this linking problem.

So it looks like the visual studio fortran project for the main program got corrupted.  I rescued it with by reverting to a backup copy of the vfproj file.  I suppose making a new vfproj from scratch would have worked too.  I like Visual Studio, but sometimes it feels very fragile.

[jimdempseyatthecove]

If you are interested in tracking this down you might want to compare the working and non-working temporary files:

"C:\Users\Brian\Documents\Visual Studio 2019\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2 new\Debug\RSP1.rsp"

They apparently differ.... .OR.

If you notice the failing condition is using ifort.exe to link, and the working one does not report any linking and I assume may be using xlink.

When ifort.exe is used for linking in the newer versions (v19.0 and later) IPO is in effect. If this is performed .AND. your dependencies describe a circular list, you may see this going into an infinite loop. In which case you may want to disable IPO or link with xlink.

Jim Dempsey

[Brian_Murphy]

Hmmm.  On my system, there are no .rsp files to look at.  What is IPO?  On my development system, I can see ifort.exe and link.exe but no xlink.exe.  I do however see xilink.exe.  How do you tell which one is used?  The buildlog doesn't show what was used in the successful build.

[andrew_4619]

rsp is just a temp file to send to the linker with a list of obj files and some maybe some options. It is created if the link command line gets too long.IPO is inter procedural optimisation which looks at all files as part of the link process or pre-process.

[Brian_Murphy]

The build log says an rsp file is created, but it must be removed.

The very first instance the link problem occurred.  Linking was taking forever and I waited and waited.  I could see large numbers of ifort.exe's in task manager.  More than a dozen.  I don't remember exactly what I did to abort the operation, but when it aborted, I'm pretty sure a messagebox appeared saying something about some problem with optimization.  That was the only time that message appeared.

[jimdempseyatthecove]

IPO stands for Inter Procedural Optimizations.
https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-interprocedural-optimization-ipo

This optimization feature can be one of: disabled, single file, multi-file

multi-file is now default.

When a large number of object files are involved, the multi-file method can take a very long time as well as consume a large amount of memory. As to if this produces a circular dependency if is unknown, this said, the "Object reader method" and/or "Table method" could potentially have issues with recursion of (included) procedures. I am not saying that this is (was) your problem.

Jim Dempsey

[Brian_Murphy]

In visual studio on the properties/fortran/optimization tab /Od is selected and Interprocedural Optimization is set to No.  In spite of that, this sure sounds like what is mucking things up.

[jimdempseyatthecove]

>>I could see large numbers of ifort.exe's in task manager. 

This indicates that option /MP is(was) enabled
In Visual Studio:

Select executable project | Fortran | General | Multi-process Compilation

You might experiment with setting this to No

In Select executable project | Fortran | Optimization | Interprocedural Optimization

You can experiment with: No, Single-file, Multi-file

And in Select executable project | Linker | Optimization | Interprocedural Optimization

You can experiment with : No, Yes

Jim Dempsey

[Brian_Murphy]

Ahhhh!  Interprocedural Optimization was set to YES on the Linker tab.  I set it to NO and linking completed.  In the project I recalled from backup, this was set to NO.

Lately I've been tackling a lot of assorted problems with this project.  Four days ago I remade the visual studio project from scratch because I thought it was the source of an earlier problem (turned out it wasn't).  If IPO is the default, that's how it got enabled.  But it was linking ok until yesterday, at which time I made source code changes to two dependent LIB projects (Arpack), and that's when linking trouble started.  Reverting to my backup copy of the vfproj file (which has this option turned off) is where I'm at right now, and all is good. 

I'm glad I now know that this option defaults to ON.

I'm hesitant to do experimenting which is not absolutely necessary because the darn thing is so fragile.

[mecej4]

It is only when a body of code has been made error-free and has produced consistent and correct output for a few days that one should start thinking of higher optimization levels than -O2. I would not want use the IFort default /fast or any level of IPO, nor specify processor preferences such as -Qxhost, during program development and debugging.

As Knuth said, "Premature Optimization Is The Root Of All Evil".

[JohnNichols]

mecej4 wrote:

It is only when a body of code has been made error-free and has produced consistent and correct output for a few days that one should start thinking of higher optimization levels than -O2. I would not want use the IFort default /fast or any level of IPO, nor specify processor preferences such as -Qxhost, during program development and debugging.

As Knuth said, "Premature Optimization Is The Root Of All Evil".

I have found code is never really error free - it merely runs and gives the correct answers sometimes. But Knuth as usual was right. 

If I add 2+2 in Fortran I am going to need several hundred lines of code to make sure everything is correct if I want a perfect answer. 

If cause if I use reals instead of real8 I will get 4.00000000195067

Got to love it. 

Brian:  I have learnt one thing in the last decade - if mecej4 tells you it is bad practice - he and JD and Dr Fortran are never wrong. 

[jimdempseyatthecove]

>>Brian:  I have learnt one thing in the last decade - if mecej4 tells you it is bad practice - he and JD and Dr Fortran are never wrong.

Thanks for the complement, however I wouldn't go so far as saying I am never wrong.

Jim Dempsey

[Steve_Lionel]

I thought I was wrong once, but I was mistaken.

Seriously, I am sometimes wrong, and I appreciate others pointing it out when that happens.

[JohnNichols]

LOL  = =  It is only when a body of code has been made error-free

No one is perfect -- although mecej4 is pretty close 

[mecej4]

Nichols, John wrote:

LOL  = =  It is only when a body of code has been made error-free

No one is perfect -- although mecej4 is pretty close 

Yes, John thinks I'm as close to perfect as machine-epsilon is to zero. Now, if I could only convince the girl's cat of that fact, ... . When I look in a mirror I get a second opinion.

When I wrote "error free", I of course meant "error free, at least as far as we can tell".

Seriously speaking, it is sobering to read papers such as http://envisage-project.eu/wp-content/uploads/2015/02/sorting.pdf , where they discuss how they wrote a program to check a widely used algorithm and found that the implementation was broken.