denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] A useful looking link for cross compiling... Re: gtk-


From: Richard Shann
Subject: Re: [Denemo-devel] A useful looking link for cross compiling... Re: gtk-app-devel-list Digest, Vol 105, Issue 20
Date: Mon, 11 Feb 2013 10:18:24 +0000

On Mon, 2013-02-11 at 00:12 -0600, Jeremiah Benham wrote:
> 
> 
> On Sun, Feb 10, 2013 at 9:51 AM, Richard Shann [...]
>         libsrfi-1... library that mxe generates.
> 
> In my system I see:
> i686-pc-mingw32/lib/libguile-srfi-srfi-13-14-v-3.a
> i686-pc-mingw32/lib/libguile-srfi-srfi-4-v-3.a
> i686-pc-mingw32/lib/libguile-srfi-srfi-1-v-3.a
> i686-pc-mingw32/lib/libguile-srfi-srfi-60-v-2.a
> which one do I need? ..or do I need all four to be statically linked
> in.
We need 
i686-pc-mingw32/lib/libguile-srfi-srfi-1-v-3.a
i686-pc-mingw32/lib/libguile-srfi-srfi-60-v-2.a

of which the first is actually used currently by denemo.scm, the second
could be used by some user written scheme. Why the other two libraries
exist is unknown, perhaps just a mistake, as the corresponding scheme
scripts srfi*.scm do not call (load-extension...) which is what is
expecting a shared object (or dll).

>  I feel this should be the job of pkg-config or guile-config or
> something. 

I really don't know what magic to use at the upper levels of autotools.
But we will need those two libraries on the link line *and* we will need
to patch two of the srfi-*.scm scripts so that instead of
(load-extension...) they have a call to the subroutines we are currently
defining in inner_main() in view.c (in the latest git that is where I
checked in the code). These are called %sfri* and are conditionally
created in the toplevel guile environment if G_OS_WIN32 is defined. The
are defined there so that when denemo.scm is called and it calls
(use-modules ...srfi...) those srfi-*.scm scripts will be able to do
their initialization.

Mark Weaver is continuing to help with the regexp problem, so things are
looking reasonably hopeful. There is at least one more looming problem,
namely this installer will not have lilypond built in and so we will
have the old problem of locating it. Perhaps we could get the LilyPond
installer and package it up with the denemo installer so as to install
both in the same place... Or write an nsis script to collect up the
LilyPond components from the gub and the denemo components from our mxe
build and install them all in one $prefix...

Richard






reply via email to

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