用的 Arch Linux
说起来我的 prompt 不是直接写了 arch 么 
使用起来稳定吗？
目前并没有遇到问题. 只有这个硬编码是我在迁移到 wsl2 时发现的
那个gcc要从哪里弄比较好呢？
不需要编译整个gcc, 只编译libgccjit, 这里有说明.
mirror的话可以选择github, 或者 gcc.git | 镜像站使用帮助 | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror
感觉太复杂了，等简单了再尝试。
有没有知道 doomemacs 怎么适配的…
emacs 已经编译完成, package 除了 core 的两个 el 的 eln 文件加上了会有错误其余的全部编译了…
目前的启动情况是: Doom loaded 626 packages across 44 modules in 2.349s
并且类似于这样的函数描述也没有出现, 还都是原先的 byte-comp
A native compiled function
fooshould then present on adescribe-functionsomething like:foo is a built-in function in ‘C source code’.
总感觉哪里不对劲…关键的是那个 626 就很迷…我总觉得所有的包启动了两遍…
eln文件是一个动态链接库，需要在path或者libaray path的环境变量里有eln文件的路径。
windows上doom-emacs用native-comp是没问题的，比普通的emacs快一点，不过还是能感觉到有点卡。
看doom的显示package没什么意义。由于已经编译成动态链接库了。所有加载的eln都能看见。windows上用vmmap.exe可以看见一个进程加载的所有的动态链接库，可以确认emacs是用了eln还是elisp。
linux上直接从/proc/$pid/maps里看。
2 个赞
确认了一下这个问题…
除了部分初始会调用的比如 evil 的一部分之外…后续的由 doom 调用的应该还是按照 byte-code 的那一套走的…就是不对劲…
把 org-mode 的 eln 删了就行了…大概跟你前面说的 advice_add 那个差不多…另外确实快了不少, 至少 magit 是十分明显的快了
我把 /usr/local/share/emacs/28.0.50/lisp/x86_64-pc-linux-gnu-16075427bc71b9f4 (custom.eln 所在目录)
加入到了 PATH LD_LIBRARY_PATH 和 LIBRARY_PATH
还是显示找不到 custom.eln, 漏了什么地方吗
又通过 lsof 测试了一下, 既能看到 /usr/local/share/emacs/28.0.50/lisp/x86_64-pc-linux-gnu-16075427bc71b9f4 目录下的库, 也有一开始编译文件夹下的库.
magit可以快，心动了！
这个一般来说给了具体的动态库的位置一般就是写死的吧。。。如果是从目录里面程序自己搜索的话应该是只给一个库的名字吧(不是很确定
我也是同样的系统, 只要用comp-speed=2,就会同样遇到这个错误, 持续关注.
To: Zhu Zihao <[email protected]>
Cc: [email protected]
Subject: Re: On elisp running native
From: Andrea Corallo <[email protected]>
Date: Mon, 09 Mar 2020 18:52:17 +0000
Hi Zhu Zihao,
Zhu Zihao <[email protected]> writes:
> I try to build native-comp branch on Archlinux. It works as expected in the
> early stage of bootstrap. But when bootstrapping leim/ja-dic/ja-dic.el with
> output:
>
> ELC+ELN leim/ja-dic/ja-dic.elc
> ...
> ...
> INFO Extracting OKURI-NASI entries...done
>
> Emacs seems to be frozen and consuming my memories little by little. And
> almost 12G RAM was consumed by Emacs when I totally terminate the process.
I believe you had just to wait and all was working. leim file are the
hardest for GCC to optimize but the most was already compiled. You can
just restart from there.
> My GCC version is https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=6957d3e4eef1f4243eb23ff62aea06139ef4415a
> both libgccjit and gcc was compiled using this commit.
>
> Have you exprienced this condition?
I've never measured the max memory consumption of the while bootstrap
but I usually count like 2GB for each compilation unit when optimizing.
Certanly some can be more demanding.
Anyway indeed the total memory consumption depends on the parallelism
you choose for building. On my main dev machine I've 32GB of ram and I
routinary build speed 2 at -j16 without problems.
To have a very raw estimation of how long it takes speed 2 you can
divide 10h by the number of CPUs you dedicate to the compilation.
> Or is there any way to ignore some file in
> native-compiling? (like no-byte-compile: t file local variable)
Not for now.
Should improve a lot when I get to implement the deferred compilation.
Andrea
--
[email protected]
简单来说就是comp-speed 2遇到leim files容易卡死，然后他目前还没计划添加排除某些文件不让他们native-comp的计划
jobs number意思是用几个Emacs进程并行编译，不是comp-speed的优化程度……
而且commit message写了fix customize type（对的，就是那个:type 'number）
进展好快啊，这不Emacs。希望作者保持这个势头。能选择只编译bootstrap用到的代码挺好的，应该能提高编译速度。