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@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@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:
"/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
- Stack can probably be resized.Proceed with caution.Available
restarts:
- (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.