Re: Has anyone tried building for Windows?

Re: Has anyone tried building for Windows?

[Mukul Sabharwal]

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
>
>

Re: Has anyone tried building for Windows?

[Dibyendu Majumdar]

On 31 July 2015 at 08:14, Mukul Sabharwal <mjsabby@gmail.com> 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:
>
> (1) `fchmod` in playback::compile_to_file::copy_file isn't supported
> on MinGW - maybe put this behind an ifdef?
>
> (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)
>
> 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.
>

Hi Mukul

That would be great - I am very interested in having libgccjit working
on Windows so that I can get Ravi using it. Please would you also post
instructions on how you built it?

Many thanks

Regards
Dibyendu

Re: Has anyone tried building for Windows?

[Mukul Sabharwal]

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:

(1) `fchmod` in playback::compile_to_file::copy_file isn't supported
on MinGW - maybe put this behind an ifdef?

(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)

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.

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

Re: Has anyone tried building for Windows?

[David Malcolm]

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.

The last time I did any Windows development was about 13 years ago, so
I'm somewhat rusty on the details.

IIRC, Cygwin and MingW-64 are two different approaches: AIUI, Cygwin is
a compatibility layer that makes Windows look like more like POSIX, and
MingW-64 is a build system for building "natively" for Windows.

> David, do you see any reason why it wouldn't work on Windows?

I believe it ought to be possible to make it work, but I'm enough of a
pessimist to think that it's unlikely to work without needing some bug
fixes, so let's figure out what's needed.

> --enable-host-shared is something nobody apparently tries on Windows.

AFAIK, it's only used by the jit, so it could well need some patches.

> Do you or any other experts have thoughts on how to proceed with a
> Windows build of libgccjit.dll?

Can you post the error messages somewhere please?  (along with the
configuration(s) you're using)

Thanks
Dave

Has anyone tried building for Windows?

[Hayden Livingston]

 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.

David, do you see any reason why it wouldn't work on Windows?

--enable-host-shared is something nobody apparently tries on Windows.

Do you or any other experts have thoughts on how to proceed with a
Windows build of libgccjit.dll?

Re: Has anyone tried building for Windows?

[David Malcolm]

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

Re: Has anyone tried building for Windows?

[Dibyendu Majumdar]

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