Lilypond and Guile forward compatibility (was RE: %module-public-interface)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Lilypond and Guile forward compatibility (was RE: %module-public-interface)

Ian Hulin
Hi Patrick,

On 02/04/10 19:50, Patrick McCarty wrote:

> On 2010-04-02, Ian Hulin wrote:
>    
>> 3. There's a  restriction introduced in Guile V2.0 whereby dynamic
>> use of define, define-public and variants will cause the guile
>> compilation to fail with diagnostics.  We have these in our basic
>> Scheme files (lily.scm and lily-library.scm).  These compilation
>> failures currently stop Lilypond building altogether.
>>      
> This is really just a stricter adherence to the Scheme R5RS.
>
> (if ...) can only contain *expressions*, IIUC, and (define ...) is a
> top-level definition, not an expression.
>
> But yes, either LilyPond will need to adapt to these stricter
> guidelines, or Guile will loosen its policy with respect to (if ...)
> statements.
>
>    
>> 4. We've already seen the %module-public-interface thing in the Lily
>> C++.  There's probably more smelly stuff lurking in the C++
>> interface, which won't surface until we start trying to use Guile
>> 2.0 more.
>>      
> I think almost everything is fixed on the C++ side now.
>
>    
I've clone the LilyPond git repo so I can play with the lily Scheme
scripts which barf with Guile 1.9.x.  If you've got any C++ patches I
can use so I can debug the .scm files I'd be grateful.  I've already got
a version of lily.scm which gets round the stuff with testing PLATFORM
to see if it's running on Windows, but I'm getting crashes during
initialization running with Guile V2.0 which I'm finding difficult to debug.

I'm trying to run lily in a
$meta/uninstalled-env bash
environment.

If I build Lilypond in a normal Guile V1.8.7 environment, and then run
it under Guile V1.9.10, I get this
ian@nanny-ogg:~/usr/src/lilypond$ out/bin/lilypond
GNU LilyPond 2.13.18
ERROR: Unbound variable: eval-when
^C
ian@nanny-ogg:~/usr/src/lilypond$




---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Patrick McCarty
Hi Ian,

On 2010-04-16, Ian Hulin wrote:
>
> I've clone the LilyPond git repo so I can play with the lily Scheme
> scripts which barf with Guile 1.9.x.  If you've got any C++ patches
> I can use so I can debug the .scm files I'd be grateful.  I've
> already got a version of lily.scm which gets round the stuff with
> testing PLATFORM to see if it's running on Windows, but I'm getting
> crashes during initialization running with Guile V2.0 which I'm
> finding difficult to debug.

I just pushed some fixes for these Guile compatibility issues.  I also
addressed the scm/lily.scm issue, so please pull and let me know how
it goes.

You'll have to run ./autogen.sh again, since I made some modifications
to the configure script.

For me, compilation now stops when scm/music-functions.scm tries to
load scm/display-lily.scm.


Thanks,
Patrick

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Ian Hulin
Hi Patrick,

On 17/04/10 03:40, Patrick McCarty wrote:
Hi Ian,

On 2010-04-16, Ian Hulin wrote:
  
I've cloned the LilyPond git repo so I can play with the lily Scheme
scripts which barf with Guile 1.9.x.  If you've got any C++ patches
I can use so I can debug the .scm files I'd be grateful.  I've
already got a version of lily.scm which gets round the stuff with
testing PLATFORM to see if it's running on Windows, but I'm getting
crashes during initialization running with Guile V2.0 which I'm
finding difficult to debug.
    
I just pushed some fixes for these Guile compatibility issues.  I also
addressed the scm/lily.scm issue, so please pull and let me know how
it goes.

You'll have to run ./autogen.sh again, since I made some modifications
to the configure script.

For me, compilation now stops when scm/music-functions.scm tries to
load scm/display-lily.scm.


  
I've just done a fresh clone of lilypond git and picked up your fixes.
I've got Guile 1.9.10, and have set up a script guile-v2
to do
exec $HOME/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/uninstalled-env bash
I executed this and then did a clean Lilypond build using the fresh git repo for lilypond.
After I patched the guile-config script to do this

#!/bin/sh
PKG_CONFIG_PATH="/home/ian/usr/lib/pkgconfig:$PKG_CONFIG_PATH"
GUILE_AUTO_COMPILE=0
export PKG_CONFIG_PATH GUILE_AUTO_COMPILE

exec "/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/guile" -e main -s $0 "$@"
!#
;;;; exec "/home/ian/usr/bin/guile" -e main -s $0 "$@"

The lilypond ./configure now runs to completion, so I did
sh autogen.sh --prefix=$HOME/usr --disable-optimising

After this, lilypond make all ran clear through to building the documentation when it terminated with a segmentation fault.

Poking around with ddd and gdb, it crashes here:

41 void
  42 ly_init_ly_module (void *)
  43 {
  44   for (vsize i = scm_init_funcs_->size (); i--;)
  45     (scm_init_funcs_->at (i)) ();
>>>>^^^^^^^^^^^^^^^^^^
crashes when i gets to 975 (initial value 980), scm_init_funcs_->size() is 981
 46
  47   if (be_verbose_global)
  48     {
  49       progress_indication ("[");
  50       scm_display (scm_c_eval_string ("(%search-load-path \"lily.scm\")"),
  51                    scm_current_error_port ());
  52       progress_indication ("]\n");
  53     }
  54
  55   scm_primitive_load_path (scm_from_locale_string ("lily.scm"));
  56 }
  57

Here's the program output from the run
GNU LilyPond 2.13.19                                                                                 
warning: Relocation: from cwd: argv0=out/bin/lilypond                                                
PATH=/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin (prepend)          
Setting PATH to /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile:/home/ian/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games                              
warning: Relocation: compile datadir=, new datadir=/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/share/lilypond//current
warning: Relocation: framework_prefix=/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin/..
Setting INSTALLER_PREFIX to /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin/..
PATH=/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin/../bin (prepend)
Setting PATH to /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin/../bin:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile:/home/ian/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR="/home/ian/usr/share/lilypond/2.13.19"
LOCALEDIR="/home/ian/usr/share/locale"

Effective prefix: "/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/share/lilypond/current"
GUILE_LOAD_PATH="/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/guile-readline:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/module:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/module"
PATH="/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin/../bin:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond/out/bin:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta:/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile:/home/ian/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
Segmentation fault
[hidden email]

The actual crash happens at a call to internal_add_interface
here
 29 SCM add_interface (char const *cxx_name,
  30                     char const *descr,
  31                     char const *vars)
  32 {
  33   string suffix ("-interface");
  34   string lispy_name = camel_case_to_lisp_identifier (cxx_name);
  35   vsize end = max (int (0), int (lispy_name.length () - suffix.length ()));
  36   if (lispy_name.substr (end) != suffix)
  37     lispy_name += suffix;
  38
  39   SCM s = ly_symbol2scm (lispy_name.c_str ());
  40   SCM d = scm_from_locale_string (descr);
  41   SCM l = parse_symbol_list (vars);
  42
  43   internal_add_interface (s, d, l);
>>>^^^^^^^^^^^^^^^^^^^<<<
  44
  45   return s;
  46 }


Any ideas?


Cheers,
Ian
Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Patrick McCarty
Hi Ian,

I decided to test the custom environment you are using, so my comments
below are in response to my new setup.

On 2010-04-18, Ian Hulin wrote:

>
> I've just done a fresh clone of lilypond git and picked up your fixes.
> I've got Guile 1.9.10, and have set up a script guile-v2
> to do
> exec $HOME/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/uninstalled-env bash
>
> I executed this and then did a clean Lilypond build using the fresh
> git repo for lilypond.
> After I patched the guile-config script to do this
>
> #!/bin/sh
> PKG_CONFIG_PATH="/home/ian/usr/lib/pkgconfig:$PKG_CONFIG_PATH"
> GUILE_AUTO_COMPILE=0
> export PKG_CONFIG_PATH GUILE_AUTO_COMPILE
>
> exec "/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/guile" -e main -s $0 "$@"
> !#
> ;;;; exec "/home/ian/usr/bin/guile" -e main -s $0 "$@"
>
> The lilypond ./configure now runs to completion, so I did
> sh autogen.sh --prefix=$HOME/usr --disable-optimising

I can't reproduce a successful ./configure run by default.  I will
list the steps I took (in detail), where "/path/to/guile-1.9.10/" is
the directory in which I compiled Guile.

- Compile Guile 1.9.10 from scratch.

- Patch the generated file "meta/guile-config", as you did above,
  though I'm not sure this is really necessary.  Is this something you
  did for a custom setup?

- Run "/path/to/guile-1.9.10/meta/uninstalled-env bash"

- In LilyPond's top source dir, run "./autogen.sh --disable-optimising".
  This command failed for me, complaining that the linker could not
  find the Guile 2.0 library (-lguile-2.0).

- After an exhaustive search, I realized that Guile's -L linker flag
  points to the directory libguile-2.0 will be copied to during
  installation.  Pre-installation, the libguile-2.0 library is located
  in libguile/.libs, which is a libtool convention, I believe.

  In other words, if I compile LilyPond with these commands,
  everything checks out, and compilation fails for me at the same
  place it did before:

    $ libguiledir="/path/to/guile-1.9.10/libguile/.libs"
    $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
    $ ./autogen.sh --disable-optimising
    $ make all


Can you test this to see if you get the same results?

Thanks,
Patrick

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Ian Hulin
On 19/04/10 01:11, Patrick McCarty wrote:

> Hi Ian,
>
> I decided to test the custom environment you are using, so my comments
> below are in response to my new setup.
>
> On 2010-04-18, Ian Hulin wrote:
>    
>> I've just done a fresh clone of lilypond git and picked up your fixes.
>> I've got Guile 1.9.10, and have set up a script guile-v2
>> to do
>> exec $HOME/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/uninstalled-env bash
>>
>> I executed this and then did a clean Lilypond build using the fresh
>> git repo for lilypond.
>> After I patched the guile-config script to do this
>>
>> #!/bin/sh
>> PKG_CONFIG_PATH="/home/ian/usr/lib/pkgconfig:$PKG_CONFIG_PATH"
>> GUILE_AUTO_COMPILE=0
>> export PKG_CONFIG_PATH GUILE_AUTO_COMPILE
>>
>> exec "/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/guile" -e main -s $0 "$@"
>> !#
>> ;;;; exec "/home/ian/usr/bin/guile" -e main -s $0 "$@"
>>
>> The lilypond ./configure now runs to completion, so I did
>> sh autogen.sh --prefix=$HOME/usr --disable-optimising
>>      
> I can't reproduce a successful ./configure run by default.  I will
> list the steps I took (in detail), where "/path/to/guile-1.9.10/" is
> the directory in which I compiled Guile.
>
> - Compile Guile 1.9.10 from scratch.
>
> - Patch the generated file "meta/guile-config", as you did above,
>    though I'm not sure this is really necessary.  Is this something you
>    did for a custom setup?
>    
No.  If I don't do this on my system, Lilypond ./configure fails with
the check saying a minimum version of guile V1.8 is not available on the
system.
> - Run "/path/to/guile-1.9.10/meta/uninstalled-env bash"
>
> - In LilyPond's top source dir, run "./autogen.sh --disable-optimising".
>    This command failed for me, complaining that the linker could not
>    find the Guile 2.0 library (-lguile-2.0).
>
>    
Hmmm..  In the past on my system, I have foolishly done a guile make
install for Guile V1.9.8.  I may still have cruft about despite doing a
make uninstall and subsequently re-compiling an installing guile V1.8.7.

> - After an exhaustive search, I realized that Guile's -L linker flag
>    points to the directory libguile-2.0 will be copied to during
>    installation.  Pre-installation, the libguile-2.0 library is located
>    in libguile/.libs, which is a libtool convention, I believe.
>
>    In other words, if I compile LilyPond with these commands,
>    everything checks out, and compilation fails for me at the same
>    place it did before:
>
>      $ libguiledir="/path/to/guile-1.9.10/libguile/.libs"
>      $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
>      $ ./autogen.sh --disable-optimising
>      $ make all
>
>
>    
Sure, but mileage may vary if my suspicion above is true,

> Can you test this to see if you get the same results?
>
>    

Willco,

Cheers,

Ian


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Ian Hulin
In reply to this post by Patrick McCarty
On 19/04/10 01:11, Patrick McCarty wrote:

> Hi Ian,
>
> I decided to test the custom environment you are using, so my comments
> below are in response to my new setup.
>
> On 2010-04-18, Ian Hulin wrote:
>    
>> I've just done a fresh clone of lilypond git and picked up your fixes.
>> I've got Guile 1.9.10, and have set up a script guile-v2
>> to do
>> exec $HOME/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/uninstalled-env bash
>>
>> I executed this and then did a clean Lilypond build using the fresh
>> git repo for lilypond.
>> After I patched the guile-config script to do this
>>
>> #!/bin/sh
>> PKG_CONFIG_PATH="/home/ian/usr/lib/pkgconfig:$PKG_CONFIG_PATH"
>> GUILE_AUTO_COMPILE=0
>> export PKG_CONFIG_PATH GUILE_AUTO_COMPILE
>>
>> exec "/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/meta/guile" -e main -s $0 "$@"
>> !#
>> ;;;; exec "/home/ian/usr/bin/guile" -e main -s $0 "$@"
>>
>> The lilypond ./configure now runs to completion, so I did
>> sh autogen.sh --prefix=$HOME/usr --disable-optimising
>>      
> I can't reproduce a successful ./configure run by default.  I will
> list the steps I took (in detail), where "/path/to/guile-1.9.10/" is
> the directory in which I compiled Guile.
>
> - Compile Guile 1.9.10 from scratch.
>
> - Patch the generated file "meta/guile-config", as you did above,
>    though I'm not sure this is really necessary.  Is this something you
>    did for a custom setup?
>
> - Run "/path/to/guile-1.9.10/meta/uninstalled-env bash"
>
> - In LilyPond's top source dir, run "./autogen.sh --disable-optimising".
>    This command failed for me, complaining that the linker could not
>    find the Guile 2.0 library (-lguile-2.0).
>
> - After an exhaustive search, I realized that Guile's -L linker flag
>    points to the directory libguile-2.0 will be copied to during
>    installation.  Pre-installation, the libguile-2.0 library is located
>    in libguile/.libs, which is a libtool convention, I believe.
>
>    In other words, if I compile LilyPond with these commands,
>    everything checks out, and compilation fails for me at the same
>    place it did before:
>
>      $ libguiledir="/path/to/guile-1.9.10/libguile/.libs"
>      $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
>      $ ./autogen.sh --disable-optimising
>      $ make all
>
>
> Can you test this to see if you get the same results?
>    
Rebuilt Guile, then

$ meta/uninstalled-env bash
$ libguiledir="$PWD/libguile/.libs"
$ export LDFLAGS="-L$libguiledir -Wl, -rpath $libguiledir"
$ echo $libguiledir
/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
$ echo $LDFLAGS
-L/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
-Wl, -rpath
/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
$ cd lilypond
$ ./autogen.sh --prefix=$HOME/usr --disable-optimising
processing .
Running autoconf ...
Running ./configure --prefix=/home/ian/usr --disable-optimising ...
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking Package... LILYPOND
checking builddir...
/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond
checking for stepmake... ./stepmake  (${datarootdir}/stepmake not found)
checking for gmake... no
checking for make... make
checking for find... find
checking for tar... tar
checking for bash... /bin/bash
checking for python... python
checking python version... 2.6.4
checking for python... /usr/bin/python
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in
`/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond':
configure: error: C compiler cannot create executables
See `config.log' for more details.
$
So now it doesn't get as far as it does on your system.

Cheers,

Ian


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Patrick McCarty
On Tue, Apr 20, 2010 at 3:51 PM, Ian Hulin <[hidden email]> wrote:

> On 19/04/10 01:11, Patrick McCarty wrote:
>>
>>   In other words, if I compile LilyPond with these commands,
>>   everything checks out, and compilation fails for me at the same
>>   place it did before:
>>
>>     $ libguiledir="/path/to/guile-1.9.10/libguile/.libs"
>>     $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
>>     $ ./autogen.sh --disable-optimising
>>     $ make all
>>
>>
>> Can you test this to see if you get the same results?
>>
>
> Rebuilt Guile, then
>
> $ meta/uninstalled-env bash
> $ libguiledir="$PWD/libguile/.libs"
> $ export LDFLAGS="-L$libguiledir -Wl, -rpath $libguiledir"
> $ echo $libguiledir
> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
> $ echo $LDFLAGS
> -L/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
> -Wl, -rpath
> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
> $ cd lilypond
> $ ./autogen.sh --prefix=$HOME/usr --disable-optimising
> processing .
> Running autoconf ...
> Running ./configure --prefix=/home/ian/usr --disable-optimising ...
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking Package... LILYPOND
> checking builddir...
> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond
> checking for stepmake... ./stepmake  (${datarootdir}/stepmake not found)
> checking for gmake... no
> checking for make... make
> checking for find... find
> checking for tar... tar
> checking for bash... /bin/bash
> checking for python... python
> checking python version... 2.6.4
> checking for python... /usr/bin/python
> checking for gcc... gcc
> checking for C compiler default output file name...
> configure: error: in
> `/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> $
> So now it doesn't get as far as it does on your system.

Hmm...

IIRC, I saw this error message too before I discovered the correct
setting for LDFLAGS.

I'm pretty sure a space is not allowed after the comma in the LDFLAGS, so

correct: $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
not:     $ export LDFLAGS="-L$libguiledir -Wl, -rpath $libguiledir"

Does it still fail if you omit the space that crept into LDFLAGS?

Thanks,
Patrick

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Ian Hulin
Hi Patrick,

On 21/04/10 00:57, Patrick McCarty wrote:

> On Tue, Apr 20, 2010 at 3:51 PM, Ian Hulin<[hidden email]>  wrote:
>    
>> On 19/04/10 01:11, Patrick McCarty wrote:
>>      
>>>    In other words, if I compile LilyPond with these commands,
>>>    everything checks out, and compilation fails for me at the same
>>>    place it did before:
>>>
>>>      $ libguiledir="/path/to/guile-1.9.10/libguile/.libs"
>>>      $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
>>>      $ ./autogen.sh --disable-optimising
>>>      $ make all
>>>
>>>
>>> Can you test this to see if you get the same results?
>>>
>>>        
>> Rebuilt Guile, then
>>
>> $ meta/uninstalled-env bash
>> $ libguiledir="$PWD/libguile/.libs"
>> $ export LDFLAGS="-L$libguiledir -Wl, -rpath $libguiledir"
>> $ echo $libguiledir
>> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
>> $ echo $LDFLAGS
>> -L/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
>> -Wl, -rpath
>> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/libguile/.libs
>> $ cd lilypond
>> $ ./autogen.sh --prefix=$HOME/usr --disable-optimising
>> processing .
>> Running autoconf ...
>> Running ./configure --prefix=/home/ian/usr --disable-optimising ...
>> checking build system type... i686-pc-linux-gnu
>> checking host system type... i686-pc-linux-gnu
>> checking Package... LILYPOND
>> checking builddir...
>> /home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond
>> checking for stepmake... ./stepmake  (${datarootdir}/stepmake not found)
>> checking for gmake... no
>> checking for make... make
>> checking for find... find
>> checking for tar... tar
>> checking for bash... /bin/bash
>> checking for python... python
>> checking python version... 2.6.4
>> checking for python... /usr/bin/python
>> checking for gcc... gcc
>> checking for C compiler default output file name...
>> configure: error: in
>> `/home/ian/Desktop/Development/Guile-and-Scheme/guile-1.9.10/lilypond':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details.
>> $
>> So now it doesn't get as far as it does on your system.
>>      
> Hmm...
>
> IIRC, I saw this error message too before I discovered the correct
> setting for LDFLAGS.
>
> I'm pretty sure a space is not allowed after the comma in the LDFLAGS, so
>
> correct: $ export LDFLAGS="-L$libguiledir -Wl,-rpath $libguiledir"
> not:     $ export LDFLAGS="-L$libguiledir -Wl, -rpath $libguiledir"
>
> Does it still fail if you omit the space that crept into LDFLAGS?
>
> Thanks,
> Patrick
>
>    
I've now rebuilt Lilypond OK after eliminating the space LDFLAGS, but it
still fails in the same place in the build.  It links the image but
Segfaults when trying to run it to build the docs,
It's still dying in ly_init_ly_module when the array pointer reaches  
976 and it's trying to execute Accidental_placement_init_ifaces().
It's not getting as far as the call to
scm_primitive_load_path (scm_from_locale_string ("lily.scm"));
which is presumable what executes lily.scm.

Cheers,

Ian



---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Patrick McCarty
Hi Ian,

On Fri, Apr 23, 2010 at 3:37 PM, Ian Hulin <[hidden email]> wrote:
>
> I've now rebuilt Lilypond OK after eliminating the space LDFLAGS, but it
> still fails in the same place in the build.  It links the image but
> Segfaults when trying to run it to build the docs,
> It's still dying in ly_init_ly_module when the array pointer reaches  976
> and it's trying to execute Accidental_placement_init_ifaces().
> It's not getting as far as the call to
> scm_primitive_load_path (scm_from_locale_string ("lily.scm"));
> which is presumable what executes lily.scm.

It seems very odd that you are seeing a segfault here.

I'm not really sure what to suggest, but can you post the backtrace
after you hit the segfault?

Does Guile 1.9.10 work okay for you in general, e.g. at the repl?

I'll post back if I discover any leads for you.

Thanks,
Patrick

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Ian Hulin
Hi Patrick,

On 24/04/10 22:00, Patrick McCarty wrote:

> Hi Ian,
>
> On Fri, Apr 23, 2010 at 3:37 PM, Ian Hulin<[hidden email]>  wrote:
>    
>> I've now rebuilt Lilypond OK after eliminating the space LDFLAGS, but it
>> still fails in the same place in the build.  It links the image but
>> Segfaults when trying to run it to build the docs,
>> It's still dying in ly_init_ly_module when the array pointer reaches  976
>> and it's trying to execute Accidental_placement_init_ifaces().
>> It's not getting as far as the call to
>> scm_primitive_load_path (scm_from_locale_string ("lily.scm"));
>> which is presumable what executes lily.scm.
>>      
> It seems very odd that you are seeing a segfault here.
>
> I'm not really sure what to suggest, but can you post the backtrace
> after you hit the segfault?
>    
Here's a gdb session screen-scrape.

Program received signal SIGSEGV, Segmentation fault.
scm_list_n (elt=0x8596ba0) at list.c:99
99      list.c: No such file or directory.
         in list.c
Current language:  auto
The current source language is "auto; currently c".
(gdb) backtrace
#0  scm_list_n (elt=0x8596ba0) at list.c:99
#1  0x0811870a in internal_add_interface (a=0x8596ba0, b=0x8596b90, c=0x85e5ab0) at grob-interface-scheme.cc:35
#2  0x081191ce in add_interface (cxx_name=0x82eb14e "Accidental_placement", descr=0x82eb1e4 "Resolve accidental collisions.",
     vars=0x82eb184 "accidental-grobs direction left-padding padding positioning-done right-padding script-priority ")
     at grob-interface.cc:43
#3  0x0805706c in Accidental_placement_init_ifaces () at accidental-placement.cc:486
#4  0x08128d41 in ly_init_ly_module () at guile-init.cc:45
#5  0x00181661 in scm_c_with_fluid (fluid=0x84b8f88, value=0x8495690, cproc=0x8128d0f<ly_init_ly_module(void*)>, cdata=0x0)
     at fluids.c:397
#6  0x001a4165 in scm_c_call_with_current_module (module=0x8495690, func=0x8128d0f<ly_init_ly_module(void*)>, data=0x0)
     at modules.c:114
#7  0x001a41cb in scm_c_define_module (name=0x83035df "lily", init=0x8128d0f<ly_init_ly_module(void*)>, data=0x0) at modules.c:175
#8  0x08128eaf in ly_c_init_guile () at guile-init.cc:63
#9  0x08161464 in main_with_guile () at main.cc:409
#10 0x001977f6 in invoke_main_func (body_data=0xbffff260) at init.c:381
#11 0x00176522 in c_body (d=0xbffff1b4) at continuations.c:475
#12 0x001ee012 in apply_catch_closure (clo=0x0, args=0x304) at throw.c:147
#13 0x00201892 in vm_debug_engine (vm=0x84d6590, program=0x848f858, argv=0xbffff090, nargs=4) at vm-i-system.c:924
#14 0x001f165a in scm_c_vm_run (vm=0x84d6590, program=0x848f858, argv=0xbffff090, nargs=4) at vm.c:518
#15 0x0017e6ed in scm_call_4 (proc=0x848f858, arg1=0x404, arg2=0x85953f0, arg3=0x85953e0, arg4=0x85953d0) at eval.c:595
#16 0x001ee9d9 in scm_catch_with_pre_unwind_handler (key=0x404, thunk=0x85953f0, handler=0x85953e0, pre_unwind_handler=0x85953d0)
     at throw.c:87
#17 0x001eeaa2 in scm_c_catch (tag=0x404, body=0x176510<c_body>, body_data=0xbffff1b4, handler=0x176530<c_handler>,
     handler_data=0xbffff1b4, pre_unwind_handler=0x1ee380<scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:214
#18 0x001767eb in scm_i_with_continuation_barrier (body=0x176510<c_body>, body_data=0xbffff1b4, handler=0x176530<c_handler>,
     handler_data=0xbffff1b4, pre_unwind_handler=0x1ee380<scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0)
     at continuations.c:452
#19 0x001768c3 in scm_c_with_continuation_barrier (func=0x1977b0<invoke_main_func>, data=0xbffff260) at continuations.c:493
---Type<return>  to continue, or q<return>  to quit---
#20 0x001edbec in scm_i_with_guile_and_parent (func=0x1977b0<invoke_main_func>, data=0xbffff260, parent=0x0) at threads.c:734
#21 0x001edd0e in scm_with_guile (func=0x1977b0<invoke_main_func>, data=0xbffff260) at threads.c:713
#22 0x0019778f in scm_boot_guile (argc=1, argv=0xbffff394, main_func=0x8161295<main_with_guile>, closure=0x0) at init.c:364
#23 0x08162888 in main (argc=1, argv=0xbffff394, envp=0xbffff39c) at main.cc:624
(gdb)

Does Guile 1.9.10 work okay for you in general, e.g. at the repl?

Yes.

> I'll post back if I discover any leads for you.
>
> Thanks,
> Patrick
>
>    
Thanks for the support.

Cheers,

Ian

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Lilypond and Guile forward compatibility

Patrick McCarty
Hi Ian,

On Sat, Apr 24, 2010 at 2:35 PM, Ian Hulin <[hidden email]> wrote:

>
> Program received signal SIGSEGV, Segmentation fault.
> scm_list_n (elt=0x8596ba0) at list.c:99
> 99      list.c: No such file or directory.
>        in list.c
> Current language:  auto
> The current source language is "auto; currently c".
> (gdb) backtrace
> #0  scm_list_n (elt=0x8596ba0) at list.c:99
> #1  0x0811870a in internal_add_interface (a=0x8596ba0, b=0x8596b90,
> c=0x85e5ab0) at grob-interface-scheme.cc:35

From what I can tell, this means that libguile compiled incorrectly on
your system.

*Or*, there might be a problem compiling Guile without optimization.

Can you reproduce this segfault if Guile 1.9.10 is compiled *with*
optimization (which is the default, I think)?

This might help narrow down the problem.

Thanks,
Patrick

---
----
Join the Frogs!