[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Multiple units into a shared object in Chicken 3.4
From: |
Thomas Bushnell BSG |
Subject: |
Re: [Chicken-users] Multiple units into a shared object in Chicken 3.4 |
Date: |
Mon, 27 Jul 2009 12:25:40 -0700 |
I found the answer!
If foo needs to be build both statically and dynamically, the following
doesn't work:
(define-extension foo)
(declare (uses bar))
Instead, the following works:
(define-extension foo
(dynamic (load "bar"))
(static (declare (uses bar)))
Thomas
On Fri, 2009-07-24 at 16:55 -0700, Thomas Bushnell BSG wrote:
> I'm using Chicken 3.4. My units are written in the following style:
>
> (define-extension foo)
> (declare (uses bar baz qux)
> (export this that the-other))
>
> If I compile them all statically, all is good. For interpreted code, I
> just load them. Of course that doesn't work for units which use the
> FFI. Those I build into shared objects with
> csc -o foo.so -s foo.scm
>
> Suddenly, for the first time, I have a unit which has a uses clause, and
> which uses the FFI. If I just do the usual thing, then when the
> compiled unit is loaded, I get "undefined symbol:
> C_other_unit_toplevel". So I'm willing to compile the other unit too,
> but no good. If I make it a .so and load it into the interpreter first,
> it doesn't work, because shared .so's don't contain C_UNITNAME_toplevel;
> they contain plain C_toplevel, of course.
>
> Ok, maybe I want to compile the two units together. But if I give -s to
> each, then I get C_toplevel in each, and they can't be linked together.
> If I compile the using unit with -s, I can't find any way to
> successfully link it to the used unit.
>
> Indeed, it seems that the C_toplevel -in-place-of- C_UNITNAME_toplevel
> difference is always tied to whether the C compiler gets -fPIC options,
> and so of course there will be no way to link things together (both
> files must be compiled with PIC, of course, but then both will get a
> C_toplevel).
>
> So how about if the using unit doesn't say "uses"? Well then, how will
> the top-level forms in the used unit get evaluated?
>
> (Especially because these files are also linked into regular
> [non-shared] programs, which rely on the uses declarations!)
>
> So basically, rather than diagnose everything--which I mostly
> understand--I'm more interested in "what is the best practice" here.
>
> I have a bunch of "library" files, used by a number of distinct
> executables. Normally, my programs are all compiled normally, and I
> want each file to be its own unit.
>
> Some of the "library" files also need to be able to be loaded into the
> interpreter. For most code, that's no problem. But some of them must
> be compiled, because they use the FFI.
>
> What is the right preamble to stick on my files, and how should they be
> compiled?!
>
> Thomas
>
>
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users