5 Jan
2020
5 Jan
'20
5:58 p.m.
If number of so files is the problem then try to build a bundle (ot even a monolithic bundle), then each library/all libraries will be in a single fas instead of a fasl-per-file. On January 4, 2020 9:57:36 PM GMT+01:00, Marius Gerbershagen <marius.gerbershagen@gmail.com> wrote: >Hi, > >> Hi list, >> I am sorry I didn't find an ECL-User mailing list, so I post this >question here. If here is not the right place to ask this kind of >question, please let me know. >> I wrote a simple GTK program using cl-gtk2-gtk, please see it >here:http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp >> >> After I installed the dependent packages using quicklisp, I ran it >with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It >compiled for about 5 hours, and emitted an error, here is the >log:http://depot.kdr2.com/scrappy/202001/ecl-gtk.log > >The important parts of the log are the errors such as > >(Error: "/tmp/ecl3258uX7y8Y.fas: failed to map segment from shared >object") > >I can't tell you exactly how to fix this, but it is clear that the >cl-gtk2-gtk system is compiling A HUGE NUMBER of files and also single >functions. This number might be simply too big for ECL to handle and >the >above error a result of some limit on the number of shared libraries >that one can load imposed by the glibc or the kernel, I don't know. > >> Then I run it again, it gave a different error: >> ```$ ecl --load ecl-gtk.lisp;;; Loading >"/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;; >Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading >#P"/usr/lib/x86_64-linux-gnu/ecl-16.1.3/asdf.fas"An error occurred >during initialization:The slot ASDF/PLAN::STAMP in the object >#<action-status >> Condition of type: STACK-OVERFLOWBINDING-STACK overflow at size >10240. Stack can probably be resized.Proceed with caution.Available >restarts: >> 1. (CONTINUE) Extend stack size2. (RETRY) Retry ASDF operation.3. >(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting >the configuration.4. (RETRY) Retry completing compilation for >#<package-inferred-system "asdf">.5. (ACCEPT) Continue, treating >completing compilation for #<package-inferred-system "asdf"> as having >been successful.6. (RETRY) Retry ASDF operation.7. >(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting >the configuration.8. (CONTINUE) Ignore initialization errors and >continue.9. (ABORT) Quit ECL unsafely, ignoring all existing threads. >> Top level in: #<process TOP-LEVEL>.> >> ``` > >I have seen errors like this before when asdf was trying (and failing) >to replace itself with a newer version. You can check whether you have >a >copy of a newer asdf in a place where asdf will search for its systems >and remove that copy. If you really need the new asdf, you need to >generate the asdf.lisp file containing all of asdf from the sources >(see >the asdf documentation for how to do that), drop that in place of the >"contrib/asdf/asdf.lisp" file in the ECL sources and recompile ECL. > >Best regards, > Marius Gerbershagen -- Wysłane za pomocą K-9 Mail.