Abdulaziz Ghuloum <[email protected]> writes:
> On Sep 4, 2009, at 12:55 AM, Andreas Rottmann wrote:
>
>> It's part of the GLib product at GNOME's bugzilla[0], select the
>> "introspection" component in that form.
>>
>> As you're to my knowledge the first person to try spells' FFI
>> abstraction on OS X,
>
> And the first person to try Ikarus, GTK, gobject-introspection, etc.,
> on Snow Leopard, so, problems can be anywhere and everywhere.
>
Indeed :-).
>> you'll have to tweak
>> "systems/spells/foreign/config.sls.in" to account for the new platform
>> (in the `c-type-alignof' function):
>>
>> When running sbank's testsuite (or spells', for that matter), you
>> should encounter an error by c-type-alignof: "unknown target", with
>> your platform's target as single irritant. I think just adding the
>> reported target to the first `cond' branch should work for OS X (from
>> what I can tell from the links at [1]):
>
> I'm building everything in 32-bit, so, I added ("darwin10.0.0" "i686")
> to the second clause, not the first. I double checked with [1] re the
> 32-bit ABI to get:
>
> --- a/spells/foreign/config.sls.in
> +++ b/spells/foreign/config.sls.in
> @@ -49,7 +49,8 @@
> (cond
> ((member target '(("linux-gnu" "x86_64")))
> c-type-sizeof)
> - ((member target '(("linux-gnu" "i686")))
> + ((member target '(("linux-gnu" "i686")
> + ("darwin10.0.0" "i686")))
> (lambda (type)
> (let ((size (c-type-sizeof type)))
> (if (= size 8)
>
>
Right, I should have looked more carefully. However, telling from your
gobject-introspection bug report, you need to run gcc with the "-m32"
flag. Since conjure doesn't add that flag, it's likely you got the wrong
numbers for `c-type-sizeof' -- can you check that
"r6rs-libs/spells/foreign/config.sls" looks sane (and temporarily fix
the numbers in there if it's wrong?). I'll add code to conjure to
inherit CFLAGS, CPPFLAGS and LDFLAGS from the environment.
> Now sbank hardcodes the foreign library names and extensions, so I had
> to get around that too. This was my temporary fix:
>
> --- a/support/shlibs.sls
> +++ b/support/shlibs.sls
> @@ -33,10 +33,10 @@
> (or (dlopen name)
> (error 'checked-dlopen "unable to open shared library" name
> (dlerror))))
>
> - (define libgir (checked-dlopen "libgirepository-1.0.so.0"))
> - (define libgobject (checked-dlopen "libgobject-2.0.so.0"))
> - (define libglib (checked-dlopen "libglib-2.0.so.0"))
> - (define libgthread (checked-dlopen "libgthread-2.0.so.0"))
> + (define libgir (checked-dlopen "libgirepository-1.0.0.dylib"))
> + (define libgobject (checked-dlopen "libgobject-2.0.0.dylib"))
> + (define libglib (checked-dlopen "libglib-2.0.0.dylib"))
> + (define libgthread (checked-dlopen "libgthread-2.0.0.dylib"))
>
> [basically "libfoo-n-n"+".so.0" => "libfoo-n.n"+".0-dylib" but that's
> still too fragile.]
>
Yep. Probably the "+" thing might vary between Darwin and GNU/Linux? I
wonder whether in that case (i.e. GNOME stack libraries), we could get
away with something like the following:
(define make-shlib-name
(case (os-name)
((darwin)
(lambda (name version)
(string-append "lib" name "." version ".dylib")))
((linux)
(lambda (name version)
(string-append "lib" name ".so." version)))
(else
(assertion-violation 'make-shlib-name "unsupported platform"
(os-name)))))
Otherwise, I'll hardcode the names for each supported platform.
> Now the fun part! These 4 tests in sbank crash the system:
>
> (test-equal (list #t #f)
> (list (test-strv-in '#("1" "2" "3"))
> (test-strv-in '#("0" "1" "2"))))
>
> (test-equal '#("thanks" "for" "all" "the" "fish")
> (test-strv-out))
>
> (test-equal '#("1" "2" "3")
> (test-strv-outarg))
>
> (test-equal '("1" "2" "3")
> (test-glist-nothing-return))
>
> Any idea as to what they may be doing in common that causes the crash?
>
They all deal with "containers" of strings. However, there are other
tests that also do so (like the "gslist" tests), and those suceed,
right?
> What does (test-glist-nothing-return) do?
>
It returns a statically allocated list (GList, to be exact) of strings,
so sbank should not attempt to free either the returned container (the
GList *) or the strings within. For debugging GNOME-related memory bugs,
disable GLib's slice memory allocator:
% export G_SLICE=always-malloc
The `test-glist-nothing-return' test is probably a good starting point
for debugging; can you fire up gdb on ikarus, and try this:
,----
| (gdb) r
| Starting program: /home/rotty/.system/bin/ikarus
| [Thread debugging using libthread_db enabled]
| Ikarus Scheme version 0.0.4-rc1+, 64-bit (revision 1854, build 2009-09-03)
| Copyright (c) 2006-2009 Abdulaziz Ghuloum
|
| > (import (sbank gobject) (sbank typelib))
| > (typelib-import ("Everything" #f) (setup gobject-setup!))
| > C-c C-c
| Program received signal SIGINT, Interrupt.
| 0x00007ffff7970570 in __read_nocancel () from /lib/libpthread.so.0
| (gdb) br ikrt_free
| Breakpoint 1 at 0x4196fa: file ../../src/ikarus-pointers.c, line 148.
| (gdb) c
| Continuing.
| 'hello
| hello
| > (test-glist-nothing-return)
| ("1" "2" "3")
| > (test-glist-everything-return)
|
| Breakpoint 1, ikrt_free (x=140737333932069) at ../../src/ikarus-pointers.c:148
| Current language: auto; currently c
`----
As you can see above, free() is not called when invoking
`test-glist-nothing-return', but is upon invoking
`test-glist-everything-return'; I suspect in your case it might be
invoked for the former and the cause for the crash (although this is
admittedly a bit of a long shot).
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
