<html><head></head><body><div class="ydpdf0d727cyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div><div><br></div><div dir="ltr" data-setdir="false">Thanks.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I checked <span>~/.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.</span></div><div class="ydpdf0d727csignature"><div style="font-size:16px;font-family:Helvetica, Arial, sans-serif;"><div><br> </div><div>Greetings.<br></div><div><br></div><div>ZHUO Qingliang (KDr2, https://kdr2.com)<br></div><br></div></div></div>
<div><br></div><div><br></div>
</div><div id="ydp339df015yahoo_quoted_9226050471" class="ydp339df015yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, January 6, 2020, 01:59:48 AM GMT+8, Daniel Kochmański <daniel@turtleware.eu> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">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.<br clear="none"><div class="ydp339df015yqt6193488882" id="ydp339df015yqtfd37415"><br clear="none">On January 4, 2020 9:57:36 PM GMT+01:00, Marius Gerbershagen <<a shape="rect" href="mailto:marius.gerbershagen@gmail.com" rel="nofollow" target="_blank">marius.gerbershagen@gmail.com</a>> wrote:<br clear="none">>Hi,<br clear="none">><br clear="none">>> Hi list,<br clear="none">>> I am sorry I didn't find an ECL-User mailing list, so I post this<br clear="none">>question here. If here is not the right place to ask this kind of<br clear="none">>question, please let me know.<br clear="none">>> I wrote a simple GTK program using cl-gtk2-gtk, please see it<br clear="none">>here:<a shape="rect" href="http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp" rel="nofollow" target="_blank">http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp</a><br clear="none">>> <br clear="none">>> After I installed the dependent packages using quicklisp, I ran it<br clear="none">>with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It<br clear="none">>compiled for about 5 hours, and emitted an error, here is the<br clear="none">>log:<a shape="rect" href="http://depot.kdr2.com/scrappy/202001/ecl-gtk.log" rel="nofollow" target="_blank">http://depot.kdr2.com/scrappy/202001/ecl-gtk.log</a><br clear="none">><br clear="none">>The important parts of the log are the errors such as<br clear="none">><br clear="none">>(Error: "/tmp/ecl3258uX7y8Y.fas: failed to map segment from shared<br clear="none">>object")<br clear="none">><br clear="none">>I can't tell you exactly how to fix this, but it is clear that the<br clear="none">>cl-gtk2-gtk system is compiling A HUGE NUMBER of files and also single<br clear="none">>functions. This number might be simply too big for ECL to handle and<br clear="none">>the<br clear="none">>above error a result of some limit on the number of shared libraries<br clear="none">>that one can load imposed by the glibc or the kernel, I don't know.<br clear="none">><br clear="none">>> Then I run it again, it gave a different error:<br clear="none">>> ```$ ecl --load ecl-gtk.lisp;;; Loading<br clear="none">>"/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;;<br clear="none">>Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading<br clear="none">>#P"/usr/lib/x86_64-linux-gnu/ecl-16.1.3/asdf.fas"An error occurred<br clear="none">>during initialization:The slot ASDF/PLAN::STAMP in the object<br clear="none">>#<action-status<br clear="none">>> Condition of type: STACK-OVERFLOWBINDING-STACK overflow at size<br clear="none">>10240. Stack can probably be resized.Proceed with caution.Available<br clear="none">>restarts:<br clear="none">>> 1. (CONTINUE) Extend stack size2. (RETRY) Retry ASDF operation.3.<br clear="none">>(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting<br clear="none">>the configuration.4. (RETRY) Retry completing compilation for<br clear="none">>#<package-inferred-system "asdf">.5. (ACCEPT) Continue, treating<br clear="none">>completing compilation for #<package-inferred-system "asdf"> as having<br clear="none">>been successful.6. (RETRY) Retry ASDF operation.7.<br clear="none">>(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting<br clear="none">>the configuration.8. (CONTINUE) Ignore initialization errors and<br clear="none">>continue.9. (ABORT) Quit ECL unsafely, ignoring all existing threads.<br clear="none">>> Top level in: #<process TOP-LEVEL>.><br clear="none">>> ```<br clear="none">><br clear="none">>I have seen errors like this before when asdf was trying (and failing)<br clear="none">>to replace itself with a newer version. You can check whether you have<br clear="none">>a<br clear="none">>copy of a newer asdf in a place where asdf will search for its systems<br clear="none">>and remove that copy. If you really need the new asdf, you need to<br clear="none">>generate the asdf.lisp file containing all of asdf from the sources<br clear="none">>(see<br clear="none">>the asdf documentation for how to do that), drop that in place of the<br clear="none">>"contrib/asdf/asdf.lisp" file in the ECL sources and recompile ECL.<br clear="none">><br clear="none">>Best regards,<br clear="none">> Marius Gerbershagen</div><br clear="none"><br clear="none">-- Wysłane za pomocą K-9 Mail.<div class="ydp339df015yqt6193488882" id="ydp339df015yqtfd24714"><br clear="none"></div></div></div>
</div>
</div></body></html>