[llvm-dev] C++ JIT Compiler with LLVM on Windows 10 - part 5

[Lang Hames via llvm-dev]

Hi All,

> I am tuning in to this thread several months late, because I am just now
trying to port our ORC-based application to Windows, and I am running into
all the same problems that Emmanuel ran into.

At first glance it does look like a COMDAT issue. Unfortunately I'm too
busy to dig in and verify that at the moment. Assuming it is a COMDAT issue
it might be either easy to fix (if it's just a failure to map correctly to
ORC's Weak linkage), or hard (if the COMDAT kind doesn't map neatly to
Weak).

I would love to see better Windows support, and I don't actually think
we're too far off having it. Unfortunately I don't have time (or a Windows
license) to dedicate to the cause at the moment. If any of you know anyone
who would be interested in spearheading that please let me know -- I'll be
very happy to consult and provide backup. Otherwise it will have to wait
until I find time, which won't happen during LLVM 13 development.

-- Lang.

On Wed, Apr 14, 2021 at 4:05 AM Stefan Gränitz <stefan.graenitz at gmail.com>
wrote:

> FYI Not sure there were specific questions open after
> https://lists.llvm.org/pipermail/llvm-dev/2021-April/149584.html
>
> On 12/04/2021 22:31, David Blaikie via llvm-dev wrote:
> > +Lang Hames
> >
> > On Thu, Apr 1, 2021 at 1:10 AM Emmanuel Roche via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> Hi Geoff!
> >>
> >> It's nice to see that other people are following this "adventurous
> path" ;-) But unfortunately, I'm afraid, I don't have anything new to
> submit on this topic: I basically stopped working on those LLVM tests
> shortly after that last discussion, since I shifted my focus to different
> tasks/concerns... :-( Eventually I would like to get back to it, but
> realistically this is not going to happen anytime soon.Now, last thing I
> see from the notes I took (but you probably already noticed that) was that
> I seemed to have reached a point where my tests were working as expected
> despite this limitation, using the code I took from llvm-link (as described
> in that section
> https://wiki.nervtech.org/doku.php?id=blog:2020:0425_jit_compiler_part5_improvements#jit_modules_linking_process
> ): so I'd say that was a working workaround in my case... but not sure it
> could apply in your situation depending on your whole
> "sources/bytecode/module processing path"...
> >>
> >> => But anyway, I wish you good luck if you decide to get your hands
> dirty on that!
> >>
> >> Cheers,
> >> Manu.
> >>
> >>
> >> Le mer. 31 mars 2021 à 15:09, Geoff Levner <glevner at gmail.com> a écrit
> :
> >>> Hi Emmanuel and Lang,
> >>>
> >>> I am tuning in to this thread several months late, because I am just
> now trying to port our ORC-based application to Windows, and I am running
> into all the same problems that Emmanuel ran into. To avoid unresolved
> symbols I have had to compile JIT modules with -D_DLL; I have had to export
> RTTI-related symbols explicitly with the same trick that Emmanuel found;
> and now I have multiple definitions of ??_7exception at std@@6B@, like
> Emmanuel.
> >>>
> >>> I see this bug has not been fixed, so my question is mostly for
> Emmanuel: have you found a workaround? I don't know exactly when this
> symbol is generated, but I have C++ modules that cannot be JIT compiled as
> a result...
> >>>
> >>> Geoff
> >>>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
> https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210414/78ae9ae4/attachment.html>