chicken-users
[Top][All Lists]
Advanced

[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





reply via email to

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