[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile 1.8 / Viper System Interface

From: Michael Tiedtke
Subject: Re: Guile 1.8 / Viper System Interface
Date: Sun, 28 Jun 2015 22:18:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Today the first successful clean room build of Viper's System Interface (still heavily recognizable as Guile 1.8) compiled successfully and ran for the first time.

Right now it's source tree of C files is about 4,5 MB on the file system with the generated 1.1 MB linux-x86_64 binary included. As a clean room branch of GNU Guile 1.8 it does away with the auto tools / libtool "foam of code and nothing" and can be compiled and linked in 30 seconds instead of 3 minutes.

What lies ahead is a lot of renaming and the drop of Guile's dynamic extension loading which provoked the core dump and isn't needed anymore. As soon as it is considered "usable" it will be available via Launchpad's Bazaar.

The short and unreadable path out of the dynamic binary plugging "libfoam" world behind me:

* Clean Build
  copy from a configured and made Guile source tree into:
** clean room layout / (it's all libguile)
   link libguile to src
*** src *.c from libguile
**** src/include
     - *.h *.x *.i.c from libguile
     - config.h, libguile.h from /
**** src/include/libguile -> .
*** src/libguile -> include
** then cmds
- rm debug-malloc.c putenv.c c-tokenize.c gen-scmconfig.c memmove.c
- =cc -pthread -DHAVE_CONFIG_H -I./include -I.. -o vsi *.c -lgmp -lcrypt -lm -lltdl=

** load-path as configured - stored in libpath.h
address@hidden:/opt/VSI/share/guile/1.8$ /opt/VSI/bin/svi
ERROR: In procedure primitive-load-path:
ERROR: Unable to find file "ice-9/boot-9.scm" in load path

** 1st coredump
address@hidden:~/Desktop/VSI-C/src$ ./vsi
guile> (version)
guile> (use-modules (oop goops))
Segmentation fault (core dumped)

* Bugs & Maintenance Issues
** Segmentation Fault for certain modules (use-module ...)
   The modules (oop goops) and (srfi srfi-1) provoke a segmentation
*** Remove the dynamic loading capability from the sources
    (see also Stacktrace)
    - no more load_extension (if applicable)
    - no more dynamic call (if applicable)
    - source file location: dynl.[c,h,x]
*** Stacktrace
(gdb) backtrace
#0  0x00007ffff5d342b9 in scm_c_make_subr () from /usr/lib/
#1  0x00007ffff5d1a048 in ?? () from /usr/lib/
#2  0x00007ffff5fbd78f in scm_init_srfi_1 ()
   from /usr/lib/
#3  0x0000000000410dd8 in scm_dynamic_call ()
#4  0x000000000042e1d2 in load_extension ()
#5  0x000000000042e235 in scm_load_extension ()
#6  0x000000000042b584 in deval ()

reply via email to

[Prev in Thread] Current Thread [Next in Thread]