Error while running a simple GTK program with ECL

[ZHUO Qingliang (KDr2)]

Thanks.
But I am still curious about why the cl-gtk2-gtk lib is compiled every time I run this simple program, I think usually it will be compiled only one time and then stored into the cache dir for the following loading.
I checked ~/.cache/common-lisp/ecl-16.1.3-unknown-linux-x64/home/kdr2/quicklisp/dists/quicklisp/software/, the compiled files (*.o and *.fas) are there, but it seems they are not used.
 Greetings.

ZHUO Qingliang (KDr2, https://kdr2.com)

 

    On Monday, January 6, 2020, 01:59:48 AM GMT+8, Daniel Kochmański <daniel at turtleware.eu> wrote:  
 
 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 at 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.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20200106/b1d44c47/attachment.htm>