Re: [Chicken-users] static library and link

[felix winkelmann]

On 5/24/06, John Cowan <address@hidden> wrote:
> > 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

Hm. Might be link-order related or some other cygwin breakage.
You could try to link by hand and put -lxy first.

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

It probably expects ".dll" instead of ".so".

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

That's ok.

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

That shouldn't be a problem. In fact, if you don't need any extensions
it's nearly trivial. Dynamic loading makes things a little bit harder.


cheers,
felix