[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Has anyone tried building for Windows?


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