Re: Has anyone tried building for Windows?

[Mukul Sabharwal <mjsabby@gmail.com>]

David,

CopyFile and GetLastError are reasonable alternatives.

LoadLibrary does not care about the file extension. Your set of
changes mentioned are absolutely the right set to make from a
LIBGCCJIT perspective, I was mentioning that my use case permits me to
just stub that piece of code out.

On the "how I built it" -- GCC 5.2 does build with the MinGW toolset,
but JIT requires --enable-shared-host and that certainly makes things
a bit interesting on Windows, so I'll collect some reasonable steps
and post them here on some repository.

Finally, I don't think I will have time to prepare a patch to
contribute to GCC, but since I benefited from LIBGCCJIT I will put all
information in the public domain so someone else can contribute it and
make LIBGCCJIT better on Windows.


On Fri, Jul 31, 2015 at 7:12 AM, David Malcolm <dmalcolm@redhat.com> wrote:
> On Fri, 2015-07-31 at 00:14 -0700, Mukul Sabharwal wrote:
>> For GCCSharp [https://github.com/mjsabby/GCCSharp], I did get GCC with
>> the JIT frontend working* but with modifications. I've been wanting to
>> tell Dave about them, so here is the very short list:
>
> Thanks for posting this.
>
>> (1) `fchmod` in playback::compile_to_file::copy_file isn't supported
>> on MinGW - maybe put this behind an ifdef?
>
> Perhaps that whole function could be replaced with a call to ::CopyFile
> on Windows? (and ::GetLastError).
>
>> (2) `dlopen` and dl* family of things in
>> playback::context::dlopen_built_dso - again, on MinGW toolset this
>> isn't available. Since this is not essential to the JIT API, maybe
>> also make this something a user can opt out of?
>>
>> So, the working* in my case was essentially generating .S files
>> (GCC_JIT_OUTPUT_KIND_ASSEMBLER)
>
> My Windows expertise is very rusty, but I believe something equivalent
> could be cooked up using ::LoadLibrary, ::GetProcAddress,
> and ::FreeLibrary.
>
> (IIRC, Windows doesn't require the extension for the jit-generated
> shared library to be ".dll"; I seem to remember in my past life as a
> game developer working with plugins for apps that had other extensions).
>
>> If there is an interest in having a LIBGCCJIT.DLL built with these
>> modifications, I can certainly make a GitHub repo with some sort of
>> binary and source drops.
>
> I'm particularly interested in *how* you built it; a recipe would be
> good to hear (I don't have a Windows development box handy, but maybe it
> can run under Wine).
>
> You mention "source drops" - note that for non-trivial changes, there
> are some legal requirements that must be followed before I can commit
> them back to the source tree; see:
> https://gcc.gnu.org/contribute.html#legal
> But if it's a case of simply #ifdef-ing a few lines out, that may be
> below the threshold (I am not a lawyer).
>
> Dave
>
>
>> Mukul
>>
>>
>> On Wed, Jul 29, 2015 at 12:51 PM, Dibyendu Majumdar
>> <mobile@majumdar.org.uk> wrote:
>> > On 29 July 2015 at 11:44, David Malcolm <dmalcolm@redhat.com> wrote:
>> >> On Tue, 2015-07-28 at 22:43 -0700, Hayden Livingston wrote:
>> >>> I've attempted to build on Windows using Cygwin and MingW-64 and I'm
>> >>> not really familiar with the build system enough but I can't make any
>> >>> forward progress.
>> >>
>> >> Thanks for trying this.  As far as I know, you're the first person who's
>> >> attempted this.
>> >>
>> >
>> > I tried a few days ago - but could not even get configure to work. It
>> > kept complaining about missing mpfr, gmp, mpc even though these were
>> > installed. I was using msys2 as the environment with mingw64
>> > compilers. In the end decided life is too short and I have many other
>> > things I need to do.
>> >
>> > Does gcc even compile on Windows without patches from mingw project?
>> >
>> > It is a pity as LLVM code generated on Windows has a serious
>> > deficiency - longjmp calls cause crash as the generated code doesn't
>> > conform to Windows requirements. I was hoping that gcc generated code
>> > would not suffer from this.
>> >
>> > Regards
>> > Dibyendu
>
>