Andrea Corallo <akrl@sdf.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Joseph Mingrone <jrm@ftfl.ca> writes:
>>
>>> Could 261d6af have broken --with-native-compilation builds on 32-bit
>>> systems?  This is what I see building in a clean FreeBSD/i386 13.0
>>> jail using 261d6af:
>>> http://pkg.ftfl.ca/data/13i386-default/2022-08-04_22h38m28s/logs/errors/emacs-devel-29.0.50.20220804,2.log
>>
>> I guess these are the error messages?
>>
>> emacs: Trying to load incoherent dumped eln file
>> /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-261d6af/native-lisp/29.0.50-7cc1a43d/preloaded/ediff-hook-0b92f1a2-f843c8a0.eln
>>
>> I don't know what that means; Andrea added to the CCs.
>
> It's very surprising to see 261d6af causing this side effect, at least I
> don't see why should effect the 32bit build only.
>
> I'm trying to reproduce it on my 32bit env.

I confirm the build it's broken on my 32bit env as well, (but not on the
64 one).

Loading the second dump, while we are relocating the ediff-hook
compilation unit, we realize (@ pdumper.c:5304) that its file field is
not a cons as expected but just a string.

Now the question is why this is not fixed-up in loadup.el:477 as for the
other compilation units?