ifx 2025 in VS2019 producing LNK1220 ??

[OldeMan]

I have a big (~1M lines, a few thousand routines) F77-vintage console app that we been building with "ifort" for years, in Visual Studio (currently VS2019).

I've just tried the new 2025 release of "ifx" and it appears to _compile_ cleanly, but refuses to link.  This is produced by an x64/debug build attempt:

Linking...
define_match_group.obj : fatal error LNK1220: 'resolving static reference symbol' requires '/WOWA64' specification

Build log written to  "file://D:/FAST_development/mod_2/VS_FAST_Build/x64/Debug/BuildLog.htm"
VS_FAST_Build - 1 error(s), 0 warning(s)

From my perspective, there is nothing unique about "define_match_group.for"... it's no different from the other thousands of routines.  So... this LNK1220 fatal error is a mystery to me.  I'm not even sure how to start?

[Steve_Lionel]

Did this object get compiled with ifx?

Interestingly, when searching for this error message I ran across Solved: fatal error lnk1220 resolving static reference symbol requires /wowa64 specification - Intel Community

[OldeMan]

Compiled with ifx?  Yep.

I'll go check out the link -- sounds promising -- thank you.

[OldeMan]

Ahh ... no.  Now that I read your link, I recognize it.  The solution was "use ifqwin" ... which my code doesn't use.  My program is a straight console app... and, as I mentioned, we've been compiling/linking via "ifort" in Visual Studio (currently 2019) for years.  For this issue, we didn't change the code -- we've only switched to "ifx" and removed a couple of diagnostic options that it doesn't support (check uninit and fp-stack-check).

I understand this error message comes from the link step, not "ifx" specifically.  But it's too vague to be helpful to me.

fatal error LNK1220: 'resolving static reference symbol' requires '/WOWA64' specification

I also understand you can't diagnose a million lines you can't see.

I'll start experimenting with it.  Maybe, if I make a change and get a different response, that'll give me a hint.

[Steve_Lionel]

I found a couple of references to this message elsewhere, but nothing seemed relevant, other than that /wowa64 is a Windows-on-ARM option not supported by the x64 linker!

Here's an experiment you can do. Open the buildlog.htm and copy the link command it uses. Open a OneAPI command prompt for x64., CD to the project folder, and paste in that command and see what happens. (You may need to edit paths first.)

[OldeMan · Accepted solution]

Here's an experiment you can do. Open the buildlog.htm and copy the link command it uses. Open a OneAPI command prompt for x64., CD to the project folder, and paste in that command and see what happens. (You may need to edit paths first.)

What an excellent suggestion.  I gave this (and one other thing) a try:

- Due to the "thousands of routines" thing, and the pathing included on each routine, the link command I found in "buildlog.html" turned out to be about 116KB long.

- Still... I opened a command prompt for OneAPI/64... and created a _linkme.txt file with the full link command embedded in it.  Then a _linkme.bat file that references the txt file.

- I decided to shorten the pathing... so now the link command is only 86KB... but, while doing so, I noticed an oddity that seems like an important tip!

- I'll give you a tiny snippet of the crazy-long link command, as copied out of buildlog.htm:

   

   Notice the "\\" in front of the one-and-only routine reported, by link, as causing a problem?

- Running (with the "\\define_match_group.obj") this gave the same error LNK1220 as reported.

- Changing that entry to "\define_match_group.obj" ... also gave the same error.

- Dang it!  Thought I'd discovered something.

- Still... out of thousands of routines... why does this ONE have "\\"... and this ONE is the one that link complains about?

- Suspicious.

I mentioned that I tried one other thing:

- I created a clean OneAPI x64 console app in VS2022 (instead of VS2019).

- I loaded all of our stuff into it -- as-is.

- I changed as little of the default setup as I could get away with ... only one build, and only the options that were absolutely required.

- and it built and ran fine!

I think I'll go with the new setup.  It'll be work to transition everything over manually, and incrementally.  But if that transition goes smoothly... we'll be up-and-running with ifx.

Thanks for your suggestions/help!

[Steve_Lionel]

I don't know why VS occasionally throws in \\ in paths - it seems to be ignored in most contexts. I'm glad to read that you stumbled upon a solution. Sometimes that is the way.