[llvm] r262188 - [PM] Appease mingw32's auto-import DLL build with minimal tweaks, with fix for clang.

[NAKAMURA Takumi via llvm-commits]

On Mon, Feb 29, 2016 at 3:53 AM Chandler Carruth <chandlerc at google.com>
wrote:

> On Sun, Feb 28, 2016 at 9:21 AM NAKAMURA Takumi via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> Author: chapuni
>> Date: Sun Feb 28 11:17:00 2016
>> New Revision: 262188
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=262188&view=rev
>> Log:
>> [PM] Appease mingw32's auto-import DLL build with minimal tweaks, with
>> fix for clang.
>>
>
> As I mentioned to you in IRC, I really dislike this change.
>
> I think this needs discussion and at least some substantial changes in the
> way of comments to explain what is going on and why it is needed.
>

Sorry. I supposed I can tweak this issue since I saw your r262127 and
r262128, that I supposed you tried to appease this issue.


If we needed to get your bot working again, I would frankly have been
> happier to just revert my patch. But now we have to live with this patch
> instead because the merge conflicts at this point will be a nightmare.
>

>
> So, can you please try to walk everyone through what the requirement is
> here? Your commit log does not contain a lot of details... My best guess
> based on the nature of your change is that mingw32 has a DLL building mode
> which is buggy because it doesn't produce a strong definition of the static
> object in the base class the derived class is defined.
>

It's also nightmare to me.

I think it is a limitation in Win32 DLL model, or mingw's binutils-ld.

For example T::PassID (instantiated with <T>), there is just but a symbol
to T::PassID, not the section of T::PassID, in the DLL image.
To link each section (and symbol) of T::PassID with the DLL that has
T::PassID, binutils-ld doesn't treat that T::PassID is defined. Just emit
the instance of T::PassID to ignore the DLL.

AFAIK, it was just the way that T::PassID (or its instantiated class)
declared as extern.



> If that is the case, I am really concerned about continuing to support
> this configuration with LLVM. We have had numerous, painful problems
> supporting mingw in the past, and this seems like it is handcuffing us
> unreasonably.
>

Cygming's BUILD_SHARED_LIBS=ON has a couple of good points;

1) Detect and keep more strict libdeps, than other shared object models.
2) Keep supporting C++ plugins on Win32.

I wish I could keep such a configuration. That said, your changes are also
straightforward and fine.
I will seek any other better way.
I don't have strong opinion whether to revert yours or to track and fix
declarations, or abandon BUILD_SHARED_LIBS.dll.

Regarding to (2), I don't recommend to resolve to tweak build scripts. I
don't want 3rd party to use special tools to create plugin.dll, but our
header files.

Do you remember what were "numerous, painful problems supporting mingw"?
AFAIK, the issue, explicit instantiation of objects, is the just one, and
others may be generic to Win32.
I did tweaks around plugin support in llvm, clang, and clang-tools. I don't
think they were painful.


And if I understand correctly, mingw32 works just fine when not using a
> particular DLL configuration?
>

Yes. I am certain that supporting mingw32 should be more straightforward
than MS SDK.
Mingw32 is just "Win32 development environment with gnu toolchain".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160229/5568bef7/attachment.html>