Resolve ecl.dll conflict on Cygwin

[williamstein]

Though the C-library interface to ECL builds on Cygwin, it does not work at all. All tests fail:

sage: import sage.libs.ecl
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/wstein/sage-4.4.3/<ipython console> in <module>()

ImportError: No such process
sage: 

The reason of this is a name clash: there are two different libraries called ecl.dll.
One in SAGE_LOCAL/lib/ and one in SAGE_LOCAL/lib/python/site-packages/sage/libs/.
It is the second one whose importing fails because it should be linked to the first one, but cygcheck shows that this dependency is resolved to itself!
This is of course dysfunctional, whence the import failure.

The easiest solution would be to rename sage/libs/ecl.pyx to something else, thus avoiding a name clash.
The solution proposed here is different and more indirect:
Patch ECL build system so that it follows the name convention proposed by Cygwin.
The shared library itself is now in SAGE_LOCAL/bin/cygecl.dll.
In addition, an import file is created in SAGE_LOCAL/lib/libecl.dll.a.

An updated spkg, based on the one in #13324, is available at
http://boxen.math.washington.edu/home/jpflori/ecl-12.12.1.p1.spkg

Reported upstream: ​https://gitlab.com/embeddable-common-lisp/ecl/issues/235

Depends on #13324
Depends on #13860

Upstream: Reported upstream. No feedback yet.

CC: @mwhansen @dimpase @jpflori @jdemeyer

Component: porting: Cygwin

Keywords: cygwin spkg ecl

Author: Jean-Pierre Flori

Reviewer: Karl-Dieter Crisman, Jeroen Demeyer

Merged: sage-5.7.beta1

Issue created by migration from https://trac.sagemath.org/ticket/9167

[sagetrac-drkirkby]

comment:1

I don't know if it's related, but gcc reports are couple of rather serious looking warning messages with ecl.

/export/home/drkirkby/sage-4.5.1/spkg/build/ecl-10.2.1.p1/src/src/c/dpp.c:678: warning: too few arguments for format
/export/home/drkirkby/sage-4.5.1/spkg/build/ecl-10.2.1.p1/src/src/c/dpp.c:680: warning: too many arguments for format

I'm surprised that gcc does not reject such code and refuse to compile it.

Dave

[kcrisman]

comment:2

I can confirm this on the most recent versions of everything at the port wiki page.

That is bad, because now the default Maxima (and hence ECL) for calculus is the library one.

[kcrisman]

comment:3

Two possibly irrelevant data points:

• Tab-completion on from sage.libs.[tab] gives sage.libs.ecl on Mac, not on Cygwin (it also doesn't give .libecm or .ratpoints, though at least ratpoints works).
• The directory $SAGE_LOCAL/lib/python/site-packages/sage/libs/ DOES include ecl.pyx and ecl.dll, so the library seems to be there, if that is where such imports actually come from (which I'm not sure about).

[kcrisman]

comment:4

A possibly useful explanation of something similar from the Cygwin list:

Now that they are in the cygwin dll, libgfortran doesn't need
> to provide them anymore but this has the unfortunate side-effect of breaking
> old executables, since on Windows an imported function reference in an
> executable has to specify not just the function name but also the particular
> DLL from which the import comes.
>
>  I imagine that on ELF platforms where the executable just has a list of
> undefined functions and a list of shared libs to load and the dynamic linker
> just satisfies an undefined symbol from whichever lib it first comes across a
> definition of it, this probably works without anything needing changing.  But
> we're stuck I'm afraid when exports move around like this.

[kcrisman]

comment:5

This stackoverflow question also might have a useful piece of information. I don't know how to open/read dlls, though, nor exactly how to trace why it is that it's not finding things.

[kcrisman]

comment:6

Cygwin's cygcheck information was much more helpful, and I find two things.

• When looking at $SAGE_LOCAL/libs/ecl.dll,

cygcheck: track_down:  could not find cyggc-1.dll

shows up a lot. I have cyggcc_s-1.dll, cyggcj-*, cyggcr-0.dll and some others, but not this, in /bin/.

• When looking at devel/sage/build/lib.cygwin.../sage/libs/ecl.dll, I find

cygcheck: track_down:  could not find csage.dll

This file is in devel/sage/c_lib and local/lib, but maybe that's not enough?

[kcrisman]

comment:7

Replying to @kcrisman:

Cygwin's cygcheck information was much more helpful, and I find two things.

• When looking at $SAGE_LOCAL/libs/ecl.dll,

cygcheck: track_down:  could not find cyggc-1.dll

shows up a lot. I have cyggcc_s-1.dll, cyggcj-*, cyggcr-0.dll and some others, but not this, in /bin/.

Mine, at least, does NOT have cyggc-1.dll anywhere. Apparently it does have libgc (this is a garbage collector) which I've seen connected to cyggc-1.dll on the Cygwin list. But I don't see how I could have libgc without cyggc-1.dll if that were the case... I guess the only thing to try is upgrading my libgc and adding libgc-devel, though I'm a little scared!

[kcrisman]

comment:8

I can't even figure out where this is created! Unless

cygwin* | mingw* | pw32*)
  version_type=windows
  need_version=no
  need_lib_prefix=no
  case $GCC,$host_os in
  yes,cygwin*)
    library_names_spec='$libname.dll.a'
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
    postinstall_cmds='dlpath=`bash 2>&1 -c '\''. $dir/${file}i;echo \$dlname'\''`~
      dldir=$destdir/`dirname \$dlpath`~
      test -d \$dldir || mkdir -p \$dldir~
      $install_prog .libs/$dlname \$dldir/$dlname'
    postuninstall_cmds='dldll=`bash 2>&1 -c '\''. $file; echo \$dlname'\''`~
      dlpath=$dir/\$dldll~
       $rm \$dlpath'

and a few similar things in the configure and aclocal files. I can't quite parse those sed things, though I am pretty sure this wouldn't produce that - but I'm not sure what ${release} would be in this context.

[nexttime]

comment:9

Replying to @kcrisman:

...
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
...

and a few similar things in the configure and aclocal files.

Where does this come from? ECL?

This might be the cause of the problem, since the sed command also replaces the lib prefix by cyg.

[nexttime]

comment:10

P.S.:

The nm and objdump utilities from the GNU binutils package might be helpful to inspect libraries etc.

I vaguely remember there was also dlltool (perhaps from the MinGW project though).

[kcrisman]

comment:11

Replying to @nexttime:

Replying to @kcrisman:

...
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
...

and a few similar things in the configure and aclocal files.

Where does this come from? ECL?

No! This is from the configure file for libgc-6.4.1 or so - the Boehm GC, ported to Cygwin. I have libgc, just not cyggc.

This might be the cause of the problem, since the sed command also replaces the lib prefix by cyg.

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

As to the tools, I think that cygcheck helped a lot, so for now I'm going to stick with that because I actually sort of understand it :)

[kcrisman]

comment:12

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

I think that libgc-devel was what it took to get this file. However, the upgrade upgraded too much - see this Cygwin list thread - so I had to downgrade libgfortran as described there, and gcc, and .... Not for the last time, I have to say that Cygwin definitely is a moving target.

[kcrisman]

comment:13

Replying to @kcrisman:

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

I think that libgc-devel was what it took to get this file. However, the upgrade upgraded too much - see this Cygwin list thread - so I had to downgrade libgfortran as described there, and gcc, and ...

...and I managed to toast my Cygwin lapack. As far as I can tell I downgraded everything necessary to the right version, rebuilt lapack, rebooted, but still no go.

$ python
>>> import numpy
ImportError <snip>

Nuts. Note that fixing this for the Cygwin Python should fix it for Sage, I think, since we use the same Fortran stuff and even lapack (?), certainly BLAS/ATLAS.

[kcrisman]

comment:14

After a lot of trouble managing to get Cygwin shell to find lapack again, I definitely have the right files now. We definitely need as at least part of the fix to add libgc-devel as a dependency.

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

This might be a PATH problem, judging by some similar issues elsewhere. Unfortunately, ./sage -gdb is no help here, nor is ./sage -ipython.

[kcrisman]

comment:15

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path? It certainly doesn't include local/lib, but I don't know if that's really the problem.

[nexttime]

comment:16

Replying to @kcrisman:

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path?

In local/bin/sage-env. You could special-case Cygwin there and add all directories that contain DLLs, as Windows treats them as executables.

It certainly doesn't include local/lib, but I don't know if that's really the problem.

Well, before editing sage-env, you could just try modifying your PATH from the shell accordingly.

[kcrisman]

comment:17

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path?

In local/bin/sage-env. You could special-case Cygwin there and add all directories that contain DLLs, as Windows treats them as executables.

It certainly doesn't include local/lib, but I don't know if that's really the problem.

Well, I have good news and bad news.

Well, before editing sage-env, you could just try modifying your PATH from the shell accordingly.

• Good news: editing PATH from the shell to include local/lib made cygcheck pass for these files.
• News: sage-env includes

if [ "$UNAME" = "CYGWIN" ]; then
    PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
fi

• Bad news: even with this added to PATH and this being in the sage-env, I still have this problem. I'm still pretty sure it's a path issue, but maybe they are in the wrong order or something? I have no idea how complex this could get...

[kcrisman]

comment:18

• News: sage-env includes

if [ "$UNAME" = "CYGWIN" ]; then
    PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
fi

• Bad news: even with this added to PATH and this being in the sage-env, I still have this problem. I'm still pretty sure

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

[kcrisman]

comment:19

Another possibility, suggested by this thread, is that there could be two of some file making things hard. Interestingly, there are several ecl.dll's floating around (everywhere a libecl.{dylib,so} would live, I guess) and cygcheck gives different dependencies for each.

[nexttime]

comment:20

Replying to @kcrisman:

• News: sage-env includes

if [ "$UNAME" = "CYGWIN" ]; then
    PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
fi

Yep, but this should IMHO be moved up in the file (including the definition of UNAME), in any case above

if [ "$1" = "-short" ]; then
    return 0
fi

and $SAGE_LOCAL/lib should be prepended to pick up Sage's versions first.

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

No idea. What does os.environ.get("PATH") give?

I also don't know if we have to add some more or different things to PYTHONPATH on Cygwin.

Note that e.g. $SAGE_LOCAL/lib/python (which is added to PYTHONPATH [if it is a directory] in sage-env) is a symbolic link on Linux etc. (pointing to $SAGE_LOCAL/lib/python2.6); I don't know if it is the real directory on Cygwin instead.

[kcrisman]

comment:21

and $SAGE_LOCAL/lib should be prepended to pick up Sage's versions first.

That sounds like a good idea. But should it be before $SAGE_ROOT and $SAGE_LOCAL/bin?

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

No idea. What does os.environ.get("PATH") give?

This gives what I would expect - Sage root, Sage local bin, usr/bin, some Cygwin stuff, a Lapack thing I had to add due to my carelessness, and then Sage local lib.

I also don't know if we have to add some more or different things to PYTHONPATH on Cygwin.

This is very sparse. It is just the directory below.

Note that e.g. $SAGE_LOCAL/lib/python (which is added to PYTHONPATH [if it is a directory] in sage-env) is a symbolic link on Linux etc. (pointing to $SAGE_LOCAL/lib/python2.6); I don't know if it is the real directory on Cygwin instead.

It looks like it's the same on Cygwin.

Another interesting thing is that there are libntl.dll files in /local/bin and /local/lib. Moving just one doesn't seem to do much - note that the bin one is the one imported usually, as in your comment above. Furthermore, apparently only the ecl.dll in devel/sage/build/sage/libs needs libntl.dll and cyggmp, while the one in local/{bin,lib} just wants cyggmp-3.dll.

Anyway, I guess I can move files around all day but I'm not getting any nearer.

[kcrisman]

comment:22

Question for Dima or others; is it possible that we have too many copies of the dlls? Either that the ecl.dll files are in too many places - local/lib and local/bin - or that the extra libntl.dll files also are causing problems? See #11635 for where this started - perhaps this is the cause of all the trouble?

[dimpase]

comment:23

Replying to @kcrisman:

Question for Dima or others; is it possible that we have too many copies of the dlls? Either that the ecl.dll files are in too many places - local/lib and local/bin - or that the extra libntl.dll files also are causing problems? See #11635 for where this started - perhaps this is the cause of all the trouble?

for the record, 2 different copies of ecl.dll in SAGE_ROOT/local/ are created; one in local/lib (and/or local/bin), created from ecl spkg, the other in local/lib/python2.6/site-packages/sage/libs/, which contains Sage/Python interface to ecl (I don't know details about how and when it is built).

[kcrisman]

comment:24

for the record, 2 different copies of ecl.dll in SAGE_ROOT/local/ are created; one in local/lib (and/or local/bin), created from ecl spkg, the other in local/lib/python2.6/site-packages/sage/libs/, which contains Sage/Python interface to ecl (I don't know details about how and when it is built).

Right, and the third one is the one which which yields "No such process".

Although just by chance I tried (in ./sage -ipython)

from sage.matrix import matrix_integer_dense_hnf
NameError: ZZ

from the import from sage.libs.ntl.ntl_ZZ even though

from sage.libs.ntl import *
ntl_ZZ

works fine. Still going to take a while to track all this down, sigh...

What do you think about the possibility that it's just a path problem suggested above? I just don't know enough about how all this works to be sure.

[kcrisman]

comment:25

Here's something interesting.

User 1@GC02635 /home/SageUser/sage-4.7.2
$ cygcheck local/bin/ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\local\bin\ecl.dll
  C:\cygwin\bin\cyggc-1.dll
    C:\cygwin\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\KERNEL32.dll
          C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\RPCRT4.dll
          C:\WINDOWS\system32\Secur32.dll
    C:\cygwin\bin\cyggcc_s-1.dll
  C:\cygwin\bin\cyggmp-3.dll
  C:\cygwin\bin\cygffi-4.dll

User 1@GC02635 /home/SageUser/sage-4.7.2
$ cygcheck local/bin/ecl.exe
C:\cygwin\home\SageUser\sage-4.7.2\local\bin\ecl.exe
  C:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\system32\ADVAPI32.DLL
      C:\WINDOWS\system32\KERNEL32.dll
        C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\RPCRT4.dll
        C:\WINDOWS\system32\Secur32.dll
cygcheck: track_down: could not find ecl.dll

Or maybe it's boring. At any rate, I find this weird.

And here is the cygcheck for the offending dll.

User 1@GC02635 /home/SageUser/sage-4.7.2/local/lib/python2.6/site-packages/sage/libs
$ cygcheck ./ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
  C:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\system32\ADVAPI32.DLL
      C:\WINDOWS\system32\KERNEL32.dll
        C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\RPCRT4.dll
        C:\WINDOWS\system32\Secur32.dll
  C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
cygcheck: track_down: could not find libpython2.6.dll

cygcheck: track_down: could not find libpython2.6.dll

cygcheck: track_down: could not find csage.dll

cygcheck: track_down: could not find csage.dll

That's a lot of things not to find.

[kcrisman]

comment:26

Scratch that - in private comm. Dima points out that we should be in the subshell.

SAGE_ROOT=/home/SageUser/sage-4.7.2
(sage subshell) GC02635:sage-4.7.2 User 1$ cd local/lib/python2.6/site-packages/sage/libs/
SAGE_ROOT=/home/SageUser/sage-4.7.2
(sage subshell) GC02635:libs User 1$ cygcheck ./ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
  C:\cygwin\home\SageUser\sage-4.7.2\local\bin\libpython2.6.dll
    C:\cygwin\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\KERNEL32.dll
          C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\RPCRT4.dll
          C:\WINDOWS\system32\Secur32.dll
  C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
    C:\cygwin\home\SageUser\sage-4.7.2\local\lib\csage.dll
      C:\cygwin\home\SageUser\sage-4.7.2\local\bin\cyggmp-3.dll
      C:\cygwin\bin\cyggcc_s-1.dll
      C:\cygwin\bin\cygstdc++-6.dll
      C:\cygwin\home\SageUser\sage-4.7.2\local\lib\libntl.dll
SAGE_ROOT=/home/SageUser/sage-4.7.2

But doing it outside its own directory yields the same "could not find" message as before. It only finds it if I'm already in site-packages/sage/.

[jpflori]

Changed work issues from use matching autoconf to none

[jpflori]

comment:110

Done (I'm aware about the not changed date in SPKG.txt but whatever).

[jdemeyer]

comment:111

Beware with timestamps when patching configure!

You must ensure that the timestamp of configure is more recent than that of the various .in files, otherwise make might want to rerun autoconf, leading to potential failures.

One solution is to edit the patch file such that configure comes last, as patch processes files in order. Or manually touch configure afterwards.

[jpflori]

comment:112

True indeed, doing that now, sorry for being that lame on this one.

[jpflori]

comment:113

Should be ok now (I've even taken the time to actually try to build it (on Linux)).

[jpflori]

Attachment: ecl-12.12.1.p1.diff.gz

Spkg diff, for review only.

[kcrisman]

comment:114

Grmph, the train's wifi cut me off...

Short version: is there anything actually different from the previous spkg that did work? I also can't see any configure changes in the patch, maybe that's a good thing.

[kcrisman]

comment:115

Okay, all relevant tests pass with this (and a rebuilt Maxima) on Mac. I say positive review, assuming JP clarifies my dumb comment about configure and he confirms that he fixed the timestamp issue (I think he is saying that he did in comment:112).

[jpflori]

comment:116

The implib.patch I posted here only touches the autotools file (you then need to somehow regenerate the build system, let's say autoreconf -i).

I've done this for the spkg, so the one included in the spkg (and in the diff posted here) is the same plus the changes to the build system (after runing autoreconf -i using matching versions of autotools).

And I've indeed reordered the spkg's patch hunks so that autotools files are patched before the build system one to ensure that autotools does not decide to regenerate everything on the fly.

[kcrisman]

Changed reviewer from Karl-Dieter Crisman to Karl-Dieter Crisman, Jeroen Demeyer

[kcrisman]

comment:117

I can no longer check this due to horrible BLODA issues but my comment:115 stands, and if Jeroen agrees that these are stamped in the correct order, then let's get this in, since it does work.

[kcrisman]

comment:118

Is it possible one might get a doctest error on this? I did a weird upgrade where I already had this ticket, from 5.6.rc0 to 5.6, and then got this.

File "/Users/karl.crisman/Downloads/sage-5.6/devel/sage/sage/libs/ecl.pyx", line 247:
    sage: inf_loop()
Expected:
    Traceback (most recent call last):
    ...
    RuntimeError: ECL says: Console interrupt
Got:
    Traceback (most recent call last):
      File "/Users/karl.crisman/Downloads/sage-5.6/local/bin/ncadoctest.py", line 1231, in run_one_test
        self.run_one_example(test, example, filename, compileflags)
      File "/Users/karl.crisman/Downloads/sage-5.6/local/bin/sagedoctest.py", line 38, in run_one_example
        OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
      File "/Users/karl.crisman/Downloads/sage-5.6/local/bin/ncadoctest.py", line 1172, in run_one_example
        compileflags, 1) in test.globs
      File "<doctest __main__.example_6[7]>", line 1, in <module>
        inf_loop()###line 247:
    sage: inf_loop()
      File "ecl.pyx", line 704, in sage.libs.ecl.EclObject.__call__ (sage/libs/ecl.c:5038)
      File "ecl.pyx", line 280, in sage.libs.ecl.ecl_safe_apply (sage/libs/ecl.c:3049)
    RuntimeError: ECL says: Console interrupt.

Note the one-character difference (on Mac, anyway). Can someone check this? I think it might be due to my having done the upgrade and thus not important.

[jpflori]

comment:119

That's expected, the first patch from #13324 should fix that.

[kcrisman]

comment:120

Hmm, that sounds familiar. Great.

[jdemeyer]

Merged: sage-5.7.beta1

[jdemeyer]

Changed upstream from None of the above - read trac for reasoning. to Reported upstream. No feedback yet.

[dimpase]

comment:123

How did you report this?
it ought to be reported here: https://gitlab.com/embeddable-common-lisp/ecl/issues

[jpflori]

comment:124

IIRC this was reported on sourceforge.net where ECL used to be hosted.

[dimpase]

comment:125

well, yes, but it seems to be lost...

[jpflori]

comment:126

At least there is a copy of the discussion on the former ECL list here:

• https://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg01978.html
  (and one in my mailbox...)

[jdemeyer]

comment:127

Could you repost that bug report to upstream?

[jpflori]

comment:128

Done:

• https://gitlab.com/embeddable-common-lisp/ecl/issues/235