[Top][All Lists]

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

Re: On elisp running native

From: Andrea Corallo
Subject: Re: On elisp running native
Date: Mon, 24 Feb 2020 23:21:02 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Andrea Corallo <address@hidden>
>> Cc: address@hidden, address@hidden
>> Date: Sat, 28 Dec 2019 08:56:17 +0000
>> Eli Zaretskii <address@hidden> writes:
>> > I'm not sure I understood you, but dlopen, dlsym etc. (or their moral
>> > equivalents) are readily available on Windows; see src/dynlib.c.  So
>> > that cannot be the reason why libgccjit is not available on Windows.
>> Sure, but libgccjit AFAIU just calls directly dlopen
>> (gcc/gcc/jit/jit-playback.c:2650).
> That's OK.  One of the MinGW flavors actually provides these functions
> directly; for the other it should be easy to write them so that
> libgccjit can call them.
>> I've just found this interesting old thread:
>> https://gcc.gnu.org/ml/jit/2015-q3/msg00124.html
> Thanks.  Not sure what to make from that, especially since AFAIK the
> Windows code is PIC by default.  The problems they are talking about
> are very easy to solve, but somehow no one has yet solved them.  Which
> might mean there's more to it than meets the eye.  (However, I'm
> talking out of sheer ignorance, so perhaps you should ask on the GCC
> list whether there are any fundamental problems with providing
> libgccjit on Windows.)

I just bumped in this Chinese blog where the guy apparently is running
the native-comp branch on Windows 10 using mingw64:


To a quick look in libgccjit he had to modify the dlopen&friends part
and added some handling for temporary files.  In Emacs comp.c code he
touched some setjmp code.

I know zero about Windows but this should help answering the question if
this port is possible and what's roughly the effort.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]