Neil Jerram writes:
> I suspect what's needed here is a patch like
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=5b98517a652ea51cbb0fd03e87a50c0b3add9707.
>
> I will upgrade to libltdl 2.2.6b, check if I can reproduce the FTBFS,
> and then see if that patc
Lucas Nussbaum writes:
>> ERROR: In procedure dynamic-link:
>> ERROR: file: "libtest-asmobs", message: "file not found"
>> FAIL: test-asmobs
>> PASS: test-list
>> PASS: test-unwind
>> PASS: test-conversion
>> PASS: test-fast-slot-ref
>> PASS: test-use-srfi
>> PASS: test-scm-c-read
>> PASS: test-s
l...@gnu.org (Ludovic Courtès) writes:
>>> meant to be used as a “normal C library”, so it should definitely go
>>> under something different from $libdir (I wasn’t clear on that when I
>>> worked on it back then.) So as time permits, I’m planning to update
>>> GnuTLS so that it installs the .so
Andy Wingo writes:
> In the alpha 1.9 series you can install them to "extensiondir". From
> NEWS:
>
> ** Dynamically loadable extensions may be placed in a Guile-specific path
>
> Before, Guile only searched the system library paths for extensions
> (e.g. /usr/lib), which meant that t
l...@gnu.org (Ludovic Courtès) writes:
> As far as the GnuTLS Guile bindings arguments, libguile-gnutls was never
> meant to be used as a “normal C library”, so it should definitely go
> under something different from $libdir (I wasn’t clear on that when I
> worked on it back then.) So as time pe
Neil Jerram writes:
> For 1.8.x extensions have to go in /usr/lib ...
Sorry, s/have to/usually/
(It's possible for Guile code to load a .so from anywhere if it
specifies the full path.)
Neil
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a su
Ludo / Andy,
Is it still the case that we recommend guile extensions to be installed
as normal libraries in /usr/lib, as opposed to some guile-specific
place? I think you were recently discussing this, and I'm afraid I
didn't pay complete attention.
(Historically this has cropped up several time
2008/11/29 Ben Hutchings <[EMAIL PROTECTED]>:
> Here's a patch that renames Guile's reimplementations of jmp_buf,
> longjmp and setjmp in the public headers. I have tested that guile-1.8
> builds on i386 and ia64 with the addition of this patch. I have not
> tested building lilypond against the m
2008/8/8 Lucas Nussbaum <[EMAIL PROTECTED]>:
> Package: guile-1.8
> Version: 1.8.4+1-2
> Severity: serious
> User: [EMAIL PROTECTED]
> Usertags: qa-ftbfs-20080808 qa-ftbfs
> Justification: FTBFS on i386
>
> Hi,
>
> During a rebuild of all packages in a lenny chroot, your package failed
> to build o
2008/5/31 Neil Jerram <[EMAIL PROTECTED]>:
> 2008/5/29 Thiemo Seufer <[EMAIL PROTECTED]>:
>> Neil Jerram wrote:
>>> 2008/5/28 Thiemo Seufer <[EMAIL PROTECTED]>:
>>> >
>>> > After a closer look I believe the logic of the test is just pla
2008/5/28 Thiemo Seufer <[EMAIL PROTECTED]>:
>
> After a closer look I believe the logic of the test is just plain wrong:
>
> aux (l) unsigned long l;
> { int x; exit (l >= ((unsigned long)&x)); }
> main () { int q; aux((unsigned long)&q); },
>
> The test returns true for a downward-growing stack,
2008/5/15 Thiemo Seufer <[EMAIL PROTECTED]>:
> Package: guile-1.8
> Version: 1.8.5+1-1
> Severity: serious
> Tags: patch
>
> Guile-1.8 currently fails to build on ia64
The ia64 problem is one that we've fixed upstream since 1.8.5, and I've
provided the patch for testing to Rob Browning (Debian m
[EMAIL PROTECTED] writes:
> Solution:
>
> change
> #ifndef YY_NO_INPUT
> to
> #ifdef YY_NO_INPUT
> in
> guile-1.8.4/libguile/c-tokenize.c :656 and :1529
>
> Should work on this error.
But unfortunately it will not continue working in the future!
I believe the correct upstream fix for this is to
13 matches
Mail list logo
