Re: [Chicken-users] static library and link

[John Cowan]

felix winkelmann scripsit:

> The simplest model is static linking - we just compile the library units
> into object files and link them with out application:
> 
> % csc -c x.scm
> % csc -c y.scm
> % csc z.scm x.o y.o -o z

I'm with you so far.

> We can also combine multiple library units into a static library:
> 
> % ar cru libxy.a x.o y.o
> % csc z.scm -L. -lxy

This, however, pukes on Cygwin as follows:

./libxy.a(y.o): In function `C_y_toplevel':
/tmp/y.c:56: undefined reference to `_C_static_string'
./libxy.a(y.o): In function `f_17':
/tmp/y.c:96: undefined reference to `_C_mutate'
./libxy.a(y.o): In function `f_19':
/tmp/y.c:105: undefined reference to `_C_bad_argc_2'
./libxy.a(x.o): In function `C_x_toplevel':
/tmp/x.c:56: undefined reference to `_C_static_string'
./libxy.a(x.o): In function `f_17':
/tmp/x.c:96: undefined reference to `_C_mutate'
./libxy.a(x.o): In function `f_19':
/tmp/x.c:105: undefined reference to `_C_bad_argc_2'
Info: resolving _C_temporary_stack by linking to __imp__C_temporary_stack 
(auto-import)
Info: resolving _C_stack_limit by linking to __imp__C_stack_limit (auto-import)
Info: resolving _C_fromspace_top by linking to __imp__C_fromspace_top 
(auto-import)
Info: resolving _C_fromspace_limit by linking to __imp__C_fromspace_limit 
(auto-import)
Info: resolving _C_timer_interrupt_counter by linking to 
__imp__C_timer_interrupt_counter (auto-import)
collect2: ld returned 1 exit status
*** Shell command terminated with exit status 1: gcc -o z z.o -lchicken 
-L/usr/local/lib -Wl,-R/usr/local/lib -L. -lxy -lpcre -lm  -lpcre

> Combining them into a shared library with explicit loading is also
> possible:

z2 links successfully but craps out at run time with:

Error: (load-library) unable to load library
x
"No such file or directory"

z2.scm: 2    load-library       <--

> But the canonical way (and the way that integrates best into everything
> and which reduces the distinction between compiled and interpreted
> code) is to compile each file into a separate shared object:

[snip]

> % csc z.scm

Recte "csc z3.scm"

This also works correctly, with compile-time warnings that extensions
"x2" and "y2" are not currently installed.

> I recommend the last approach, unless you have really many different
> libraries and want to package them in one binary - then the load-library
> approach is appropriate.

What I want to do for Joy-in-Scheme purposes is to deliver C code
that can be statically linked into one executable according to the
plan of manual section 3.5.

However, it seems to me that all the things you describe ought to work.

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 address@hidden
isn't a man.    --Jewish saying