[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Chust
Subject: Re: [Chicken-users] Units as shared libraries (SWING, dynamic, does not work)
Date: Sat, 11 Dec 2004 16:10:22 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040918)


Joel Reymont wrote:

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 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 ./ ...
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

 ((or chicken-compile-shared shared)
  (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

 ((or chicken-compile-static static)
   (declare (uses my-unit-name)))
  (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 ;)



reply via email to

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