In http://reviews.llvm.org/D10737#195406, @zturner wrote:
> I don't really know much about MinGW, and i also am not in a position to be > able to look at any code right now as I'm technically OOO for another 3 > weeks. That said, if it is possible to make this work as a delayload dll, > it would be much preferred, even if it strays from some existing > implementation that does something different. With MSVC, this is as simple > as adding a linker flag, and you don't have to change even 1 line of code. > I'm not sure if MinGW toolchain supports this, but please check first. I'll > leave the final lgtm to someone else on this review. I have checked MinGW possibilities and have not found easy way for delay loading. So at this moment I see following aproaches for this issue: 1. Leave manual loading for MinGW in the code but use MSVC -delayload linker flag. The main drawback of this approach is two different ways for implementing lazy loading of imghelp.dll. 2. Use dlltool (https://sourceware.org/binutils/docs/binutils/dlltool.html) for MinGW to generate imghelp.a file with lazy loading and simple -delayload linker flag for MSVC. This approach removes manual loading code from the patch, but adds configuration code for launching dlltool and most probably def file. Moreover, some of MinGW implementations don't provide --output-delaylib parameter (for example, 4.3 and lower). So building of LLVM may be impossible for this versions. 3. Use manual loading for both compilers. This approach has evident benefit with same implementation for both compilers (msvc, mingw) and without using of extra tools. REPOSITORY rL LLVM http://reviews.llvm.org/D10737 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
