linking with OLD (circa 2011) .a files

[RayMaple]

We have a commercial engineering application that consists of several fortran applications that are recompiled/linked every time they are run.  The core of the application is shipped as .a library files, last compiled in 2011.  We have spoken with the vendor, and there is no possibility of getting a newer version.  We have been successfully using this software with parallel studio 2020.4.304, ifort version 19.1.3.304, for which we have a perpetual floating license.  Unfortunately our license server hardware is at risk of failing, and we need to rehost to new hardware, which will require new keys.  We no longer have paid support for parallel studio.  I've tried using the legacy ifort compiler included in the latest oneapi release, but the linked executables fail with a fatal forrtl internal consistency check failure.   Note that in the first failing app, ifort is used only to link a bunch of .a files - no actual compilation takes place, so the issue seems to be a runtime/linker incompatibility.

I posted a question in the licensing forum asking if there is any way to get a key for a new host, but it would be much better to get this working with oneapi.  Any suggestions for a technical solution are greatly appreciated.

[Steve_Lionel]

The issue is not link-related, but somehow the runtime library is failing to support the calls in the old .a, despite it being a policy of the Fortran project to always be upward-compatible (old objects with new libraries.) Can you identify the particular call from the .a that is triggering the issue? If there's a traceback, you should be able to figure this out from a link map.  

If I were trying to analyze this, I'd probably step through it with the debugger to find the problem call, then compare to what should be the similar call from an object compiled with the current compiler to see what the difference is.

Does it behave differently if you compile/link with -static ?

[RayMaple]

Thanks for the suggestions.  The code is compiled with -static-intel.  ldd shows the only shared libraries used are libc, libm, libgcc, etc.  I can try stepping with the debugger if I can figure out how to invoke it.  This application dates back to ye olden CRAY days, and goes through a lot of file staging, source splitting, compiling, scripts calling scripts, etc. before it actually runs the executable on heavily modified inputs.  I have made a little progress though.  I've managed to find an environment setup that gets past the internal consistency error.  The first stage is now crashing with error (76) abort trap signal.      The stack trace shows Unknown for most routine, line and source, so the object files were most likely stripped (or at least -g was not used) before creating the .a files.  The one identified routine seems to hint that it was echoing an input file when it died, so maybe some sort of IO error?   I did get a runtime warning about a rewind on a terminal device being a no-op, but I doubt that is causing the problems.