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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/chicken-users _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
