Re: [Chicken-users] Units as shared libraries (SWING, dynamic, does not work)

[Thomas Chust]

Hello,

Joel Reymont wrote:
> Folks,
>
> Here's the issue. Very simple to reproduce:
>
> ;;(declare (unit bar))
>
> (define stuff 
>         (lambda () (display "Stuff!\n")))
>
> Place the code above in bar.scm. It will compile with "csc -s bar.scm"
> and produce a shared library bar.so. You can load this library with
> "(require 'bar)" even if you are in the directory where you compiled it.
>
> Uncomment the unit declaration and the library will compile again but you
> will get the following error when trying to load it:
>
> #;1> (require 'bar)
> ; loading ./bar.so ...
> Error: unbound variable: |\þ\í\ú\Î\\\\\\\\\\\\\\|
>
> I get the same error with Chicken 1.66 and 1.74 on Mac OSX.

as far as I can see, this is not a system specific problem. It also 
doesn't work on my linux box.

> I searched the archives and saw Felix saying that units weren't meant to
> be compiled with -dynamic. I need to wrap a couple of C++ libraries for
> my project and SWIG wraps libraries in units. It would not be a problem
> for me to remove the unit declaration but I'd rather not.
>
> Is there a particular reason for this restriction? How can I work around
> this issue?

I don't know, why this restriction exists, although I think the reason 
is that it's just easier to hardcode a dynamic function load call for 
"C_toplevel" instead of "C_<unit-name>_toplevel" especially because the 
unit name would not necessarily be correlated with the shared object's 
name...

I work around this problem by including something like

(cond-expand
 ((or chicken-compile-shared shared)
  )
 (else
  (declare (unit my-unit-name))))

at top of the unit's source code. By the way, I would suggest to add a 
feature to csc: The compiler should declare the features static and/or 
chicken-compile-static as available when compiling code with the -static 
option beause then you could equally easily write something like

(cond-expand
 ((or chicken-compile-static static)
   (declare (uses my-unit-name)))
 (else
  (require-extension my-unit-name)))

in the code that uses the unit -- and everything would work fine whether 
compiling statically linked executables or not!

If you have dynamically generated scheme code including unit 
declarations, you could, if it was absolutely necessary not to modify 
it, rewrap the code by writing another scheme file which would import 
the unit in question and reexport all its symbols. This file you would 
compile and link together with the original compiled wrapper code into a 
shared object. But I admit that this is a clumsy solution (and also an 
untested one ;)

> [...]

Ciao,
Thomas