On Mon, 27 Apr 2020, Steve Lhomme wrote:
The library already existed for projects correctly using it, but the actual code was in libmingw32.
So practically, this will most probably break all projects that use the feature, as they most probably haven't added -ldelayimp - as they haven't needed so far.
There is also a configure option to enable delay loading support (off by default). So It's only built when it's enabled.
No, we should keep building the delayimp helper library regardless of that option.
That option controls whether a separate delayimport version of all import libraries are built. (They don't seem to be installed though - if they did, it'd inflate the size of the installation quite a bit as well.)
The concept of a separate delayimport library only exists with binutils - llvm-dlltool doesn't implement that option, and with lld (with msvc style import libs, which is what llvm-dlltool generates) you use the normal import libraries, just pass a separate option for linking a specific library in delayimport mode.
So for llvm based tools, we can't enable the --enable-delay-import-libs option as it is right now, but we'd still need libdelayimp.a.
And for binutils based tools, even if you don't enable that option (and even if you did, you didn't get those files installed), users may have cases where they just generate the delayimport libraries from a specific def file, without building the whole crt that way.
// Martin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
