Backward compatibility breaks when /GL used

Question

In order to build our applications for ARM64 devices, we upgraded VS 2017 15.5.7 to 15.9.6 version. Post that, libraries built(15.9.6) with /GL flag now throws "unrecognized flag" errors as below when used by test apps(built on 15.5.7):

1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed

Once the "Whole program optimization (/GL)" is disabled in project settings, the client build passes.

Could anyone check what has changed from 15.5.7 version to now throw this linking error? Also what is the suggested project setting for best optimization.

Answer 1

You are right when you say that backward compatibility is broken when using this option.

Officially :

Whole program optimization allows the compiler to perform optimizations with information on all modules in the program. Without whole program optimization, optimizations are performed on a per module (compiland) basis.

And, still officially, even though it is mentioned to be between Visual Studio 2015 and Visual Studio 2017 :

Binary compatibility is not guaranteed in these cases:

1. When static libraries or object files are compiled with the /GL compiler switch.
2. When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12. Also, binary compatibility only exists between Visual Studio 2015 and Visual Studio 2017; linking 19.x programs with libraries produced by Visual Studio 2013 or earlier is not supported.

But unofficially, I can say that :

Using this compiler option, if one of your dependencies is built with a different compiler update (even some minor update), the link will almost certainly fails.

In fact, the /GL compiler option is so restrictive concerning backward compatibility between DLLs and EXE, that we decided not to use it anymore in our company.

We have a LOT of DLLs, and EXEcutables are built on different projects.

To keep things short, when debugging, we sometimes need to build exe with newer compiler while using libs compiled with older compiler.

This flag prevents doing exactly that.

Possible solutions that may help others :

• Rebuild the old libraries with old compiler without the flag
• Rebuild the old libraries with the new compiler while keeping the flag (that means to always rebuild them when a new compiler arises)
• Rebuild the new executable with the old compiler (that means no compiler update)