Problems with Lush in OsX Snow Leopard

  • Carlos E. Mejia

    Carlos E. Mejia - 2010-01-29


    Hello to Leon and all Lush people, and Bonne Annee !!

    Well, here is my help call ;-) I try compiling Lush in the latest OsX system
    for Macs, Snow Leopard, or 10.6 and I have finally succes on compiling but two
    problems persist :

    (1) No window system: when doing (helptool) the system do not recognize
    the windows system. I have the error message "*** ogre : Unsupported window
    system" and obviously no windows appears. I use X11 and not the Terminal of

    (2) when trying to load modules there is a GASP error :

    ? (load "libc/stdio")

    Preprocessing and parsing idx-f1resize …
    Preprocessing and parsing idx-f2resize …
    … etc …
    Generating C for idx-d3resize …
    Generating C for idx-d4resize …
    gcc -DHAVE_CONFIG_H -DNO_DEBUG -Wall -O3
    -I/usr/local/Lush/OsX10.6_32b/share/lush/include -I/usr/X11/include
    -I/sw32/include -I/sw32/include/freetype2 -c
    /Users/rezo/.lush/lsh/libidx/C/idx_macros.c -o
    dyld: dyld std::terminate()

    **** GASP: Severe error : Signal 5 has occurred
    **** GASP: Trying to recover
    **** GASP: You should save your work immediatly


    I have no idea about what can cause and how to solve those problems …

    Thanks for any help.


    PS: for those interested in more precision. I'm installing Lush in a new 27"
    iMac with Core 2 Duo processor, 8 GB RAM and MacOS X 10.6.2. Xcode, or the
    developers tools, is the latest, version 3.2.1.

    I use Fink packages for installing second part software like readline, curses,
    freetype, etc. Fink can be installed in 32 or 64 bits in Snow Leopard. I
    install both in order to see their differences and to experiment developing
    with both. I use thus /sw32 and /sw64 as directories for installing. I create
    two users, admin and admin64, in order to avoid conflicts in the environment
    files and variables.

    Compiling Lush in 64 bits Fink environment was straight forward. No errors.
    But when executing I have the same two problems that I talk above.

    We had more difficulties when compiling with 32-bits Fink. First, compilation
    show me problems with readline, curses and freetype libraries, and some
    undefined symbols :

    gcc -DHAVE_CONFIG_H -DNO_DEBUG -Wall -O3 -I../include
    -I/sw32/include/freetype2 -I/sw32/include -I/usr/X11/include -c unix.c
    g++ -DHAVE_CONFIG_H -DNO_DEBUG -Wall -O3 -I../include
    -I/sw32/include/freetype2 -I/sw32/include -I/usr/X11/include -c cpp.cpp
    g++ -DHAVE_CONFIG_H -DNO_DEBUG -Wall -O3 -I../include
    -I/sw32/include/freetype2 -I/sw32/include -I/usr/X11/include -o lush
    allocate.o at.o binary.o calls.o arith.o check_func.o classify.o date.o
    dump.o dz.o eval.o fileio.o fltlib.o function.o event.o graphics.o htable.o
    idx1.o idx2.o idx3.o idx4.o index.o io.o dh.o lisp_c.o main.o module.o nan.o
    oostruct.o ps_driver.o comdraw_driver.o lisp_driver.o storage.o string.o
    symbol.o toplevel.o user.o unix.o cpp.o -L/sw32/lib -L/usr/X11/lib
    -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -lXft -lXrender
    -lfontconfig -lfreetype -lz -lX11 -lreadline -lcurses -lutil -ldl -lm
    ld: warning: in /sw32/lib/libfreetype.dylib, file is not of required
    ld: warning: in /sw32/lib/libreadline.dylib, file is not of required
    ld: warning: in /sw32/lib/libcurses.dylib, file is not of required
    Undefined symbols:
    "_rl_line_buffer", referenced from:
    _console_complete in unix.o
    _console_complete in unix.o
    … more …

    I found that there was 64 bits versions of readline and curses in Fink
    (readline5-64bit and libncurses5-64bit). I install it with the corresponding
    shlibs. Now, I had problems only with freetype and undefined symbols:

    ld: warning: in /sw32/lib/libfreetype.dylib, file is not of required
    Undefined symbols:
    "_rl_getc", referenced from:
    _console_getc in unix.o
    "_rl_basic_quote_characters", referenced from:
    _init_unix in unix.o
    "_rl_insert_close", referenced from:
    _init_unix in unix.o
    "_rl_set_paren_blink_timeout", referenced from:
    _init_unix in unix.o
    ld: symbol(s) not found
    collect2: ld returned 1 exit status
    make: *** Error 1
    make: *** Error 2

    Finally, I give the path to 64 bits library for link edition process in the
    ./configure step :

    LDFLAGS="-L/sw32/lib/x86_64" ./configure -prefix=/my_install_path

    and compilation works fine. When I try this newly compiled lush program it
    runs but I have the same two problems as for the 64-bits version.

  • nlb666

    nlb666 - 2010-02-25

    When I compiled from CVS under Snow Leopard, I didn't get the GASP errors, but
    still no joy with X.

    I also cannot install under OpenBSD (libbfd problems) or Ubuntu…. It appears
    lush isn't exactly well maintained in terms of ports to different systems!

  • Yann LeCun

    Yann LeCun - 2010-02-25

    I'm not sure what you are referring to: the CVS version works like a charm on
    I use it every day, and so does my entire lab.

    • Yann
  • nlb666

    nlb666 - 2010-02-26

    To be clear: the CVS version compiles under Mac OSX Snow Leopard, with no GASP
    errors, but X doesn't work. The tar does not compile.

    On Ubuntu, the latest tar does not compile (Ubuntu 8.04). The version from
    apt-get does compile and appears to work. I didn't try CVS on Ubuntu.

    On OpenBSD, I can't coerce the thing into recognizing where bfd and libiberty
    are living (in the /usr/local/… dirs not /usr). I did not try CVS on OpenBSD
    either. This system is my preferred target so advice on ./configure would be
    most welcome.

  • Yann LeCun

    Yann LeCun - 2010-02-26

    OK, thanks for the clarification. The tar version is a little out of date,
    since Lush2 is in beta.
    I've never tried BSD, but I really think you should try the CVS version.

    • Yann
  • Carlos E. Mejia

    Carlos E. Mejia - 2010-02-26

    Yes, it compile but have you tried to load modules, like (load "libc/stdio")
    It's hera I have the GASP message …


  • Yann LeCun

    Yann LeCun - 2010-02-26

    works fine here. It works fine for everyone else I talk to. There must be
    something wrong with your config.

    • Yann
  • Carlos E. Mejia

    Carlos E. Mejia - 2010-02-26

    hum, … ok Yann , thanks for your answer. I will try it again, but I cannot
    give news before some days because holidays.


  • tourtelt

    tourtelt - 2010-11-26


    I also get the GASP message on Mac OS X 10.6 when I do certain libloads. This
    is using a fresh check-out of lush from CVS. For example:

    ? (libload "idx-macros")

    dyld: dyld std::terminate()

    ^G**** GASP: Severe error : Signal 5 has occurred
    **** GASP: Trying to recover
    **** GASP: You should save your work immediatly

    Is there a Mac user out there who can respond to this? thanks,

  • Yann LeCun

    Yann LeCun - 2010-11-27

    I'm not a Mac user, but my understanding is that, in revision 10.6 of OS-X,
    Apple decided to change the format of object files (.o) from ELF (which is
    standard in the Unix world) to something called Mach-O. Unfortunately, the
    Lush dynamic loader is built around libbfd, which doesn't support Mach-O. So
    the Lush dynamic loader doesn't work, and the compiler is rendered useless.
    Library files that don't have a "dhc-make" (no compiled code) will load
    fine, but those that do will crash.

    • Yann
  • Scott Locklin

    Scott Locklin - 2010-11-27

    I thought of building a script around this utility to work around to Mach-O

    But considering some of the other problems I've had to deal with, I'm taking
    it more as a cue to abandon OS-X.

  • Corey Hoffstein

    Corey Hoffstein - 2010-12-11

    Any chances of this ever getting fixed? I would really like to use Lush, but
    it seems pretty unusable on 10.6…

  • Yann LeCun

    Yann LeCun - 2010-12-12

    I'm not an OS-X user/hacker and I have no idea if a fix is possible. I guess
    Slocklin's proposal is our best bet.
    Slocklin: any luck with the script?
    Anyone else out there with a bright idea?

    • Yann
  • Scott Locklin

    Scott Locklin - 2010-12-12

    I'm happy to donate my old Macbook to the cause if someone can convince me
    they'll seriously tackle the problem. I haven't used it in a year for this
    reason, and don't have the time to dedicate to such a project.

    Another potential work around is to configure an older version of gcc for the
    mac. I sort of recall reading that one could get older versions of gcc to
    compile into ELF if you fiddle with it enough.



Log in to post a comment.