Just to confirm, adding macroexpand to native-comp-never-optimize-functions
allows me to build successfully.

It also looks like comp-delete-or-replace-file can be updated to protect
rename-file against file-already-exists like it does for Windows. That
would also likely solve the problem if you want to be able to optimize
macroexpand.




Aaron


On Fri, Dec 29, 2023 at 3:26 PM, Aaron Jensen <aaronjensen@gmail.com> wrote:

> On Fri, Dec 29, 2023 at 3:17 PM, Andrea Corallo <acorallo@gnu.org> wrote:
>
> Aaron Jensen <aaronjensen@gmail.com> writes:
>
> Yes, that's what I've found. I can also confirm that compiling with 1
> thread works around it. It's only a problem w/ gmake -jN where N is > 1 (I
> run w/ 8 or 12 or so typically).
>
> Aaron
>
> Intresting, adding Jens, hopefully he has some good idea.
>
> Maybe you could re-add 'macroexpand' and 'rename-buffer' to
> 'native-comp-never-optimize-functions' and discover which one of the two
> is triggering the bug?
>
>
>
> I can't try it just now, but my trace includes: `File already exists:
> /private/var/tmp/emacs-plusA30-20231227-10652-1cz0rs/.brew_home/.emacs.d/eln-cache/30.0.50-69afc345/subr--trampoline-6d6163726f657870616e64_macroexpand_0.eln`
> so I'm guessing it's macroexpand.
>
> Aaron
>