Bug report: Loading a FASL into a package which doesn't import SETQ

Erik Huelsmann ehuels at gmail.com
Tue Nov 10 14:06:22 UTC 2020


Hi,

On Tue, Nov 10, 2020, 11:50 Mark Evenson <evenson at panix.com> wrote:

>
>
> > On Nov 8, 2020, at 22:48, Robert Munyer <2433647181 at munyer.com> wrote:
>
> […]
>
> > A proper fix would probably involve binding *PACKAGE* to a package in
> > which none of the symbols that are in the content that is about to be
> > written to __loader__._, other than keywords, are present or inherited.
>
> Unfortunately, it doesn’t seem to be as simple as that.  Or maybe I am
> still
> confused, because apparently I have a bug in the zip-cache used by our
> falls so
> I end up calling SYS:CLEAR-ZIP-CACHE.
>
> Anyways, I have made [some progress][1] on this, but even with this patch
> we
> still fail when loading a fasl the current package doesn't (use :cl) if the
> source file doesn’t have an explicit :IN-PACKAGE.  The failing test works
> in
> SBCL/CCL so there is definitely something wonky in our loader
> implementation.
>

To be honest, I think the problem is with the FASL generator: it should be
prefixing (all) symbols with their packages when that's required to load
the FASL back into a similar environment.

Regards,

Erik.

>
> [1]: <https://github.com/armedbear/abcl/pull/352>
>
> More when I know it,
> Mark
>
> --
> "A screaming comes across the sky.  It has happened before but there is
> nothing
> to compare to it now."
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20201110/ce8c5e06/attachment.htm>


More information about the armedbear-devel mailing list