[cfe-dev] Exec compiled with clang-cl loads extra dlls when build

[Reid Kleckner via cfe-dev]

Hard to say. Personally, I've never used dependency walker (depends.exe?),
and I'd approach the problem with dumpbin /imports and dumpbin /dependents.
I'd start at the bottom of the dependency graph, gather the lists of
imports, and look for major differences. One thing we've noticed in the
past is that the order of DLLs in /dependents matters for reasons like
these.

Regarding the std::allocator<char> constructor, I think that's expected.
Both DLLs are supposed to instantiate the allocator template, and there
should be two templates. They aren't supposed to import from each other,
and everything should be fine.

On Sat, Nov 24, 2018 at 11:28 PM JVApen via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Hello all,
>
> I'm working towards converting an MSVC application to compile and run with
> Clang-cl.
> Over the last years, we've make a lot of progress on this.
> Today however, I'm facing a problem I don't understand and hope that you
> will be able to help me with this.
>
> When I build a single application from a monolithic code base, the
> executable works. (Thanks a lot for all of the effort to allow this!)
> However, if I build all of the executables (and extra dlls), the
> executable crashes.
> From what I can tell, the problem is the following:
>  - Exe starts
>  - Dll_A gets loaded
>  - Dll_A has a dependency on Dll_B
>  - Dll_B gets loaded
>  - Dll_B depends on Dll_A => Circular dependency
>
> However, when building a single executable, Dll_B was not build and Dll_A
> doesn't seem to depend on on Dll_B.
>
> I've looked through this with dependency walker and found 2 reasons why
> Dll_A depends on Dll_B:
>
> Following code exists in the code of Dll_A
> class I { virtual I *clone() const = 0; }
> class EXPORT Impl { virtual Impl *clone() const { return new Impl{*this}; }
>
> Dependency walker indicates that Dll_A contains:
>    Impl *Impl::clone() const
> It also indicates that Dll_B contains:
>    I *Impl::clone() const
> This last is a bit unexpected to me, however, covariance is not my
> expertise.
>
> I've updated the code to not use covariance just to test.
> This again causes a circular dependency, because now a Dll_C (and depends
> on Dll_B) contains following symbol where Dll_A depends on:
>     std::allocator<char>::allocator<char>(std::allocator<char> const &)
>
> I wouldn't even know how to update the MSVC STL, nor would I want to do so
> as this is an external library.
>
> Do you have any idea on what is causing this and how to get started on
> creating a reproduction for this? (And no, I unfortunately can't use
> CReduce)
>
> JVApen
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181126/6531c69b/attachment.html>