[Ecls-list] Missing symbols when embedding a static lib into a FAS file

[Goffioul Michael]

Hi,

I'm facing a linkage problem when trying to build our framework on Linux
(it works
OK under Windows). The problem is the following:

1) several LISP files are compiled and linked into a static lib with
c::build-static-lib
	-> (c::build-static-library "mylib" :lisp-files '(<my objects>))
=> libmylib.a

2) a FAS file is generated using this static lib, with c::build-fasl
	-> (c::build-fasl "myfas" :lisp-files '(mylib)) => myfas.fas

Step 1 will generate a static lib containing the symbol init_MYLIB to
initialize the
module. Step 2 will generate a dynamic lib containing the symbol
init_CODE, which in
turn calls init_MYLIB. Now, this function call is indirect, as
init_MYLIB symbol is
searched by name using ecl_library_symbol. As the symbol init_MYLIB do
not actually
appear in the init_CODE function of the fas file, the linker will NOT
embed the 
corresponding code in the generated FAS file. The result is that loading
the resulting
FAS file just segfaults (indeed, ecl_library_symbol will return NULL),
the stack trace
being:

#0  0x0000000000000000 in ?? ()
#1  0x0000002a9574ae7d in read_VV (block=0x6e59a0, entry_point=0) at
read.d:1978
#2  0x0000002a95df5a48 in init_CODE (cblock=0x6e59a0) at
ECLINITS69MYC.c:39
#3  0x0000002a9574b0c5 in read_VV (block=0x6e5a10,
entry_point=0x2a95df59f8 <init_CODE>) at read.d:2023
#4  0x0000002a957693d7 in si_load_binary (filename=0x8a3ea0,
verbose=0x2a958dd3c0, print=0x5771d0) at load.d:298
#5  0x0000002a9577968f in APPLY_fixed (n=7231904, fn=0x58cd33,
x=0x2a95a26788) at apply.d:676
#6  0x0000002a95735c9d in cl_funcall (narg=3, function=0x2a958ee730) at
eval.d:216
#7  0x0000002a957698b6 in cl_load (narg=182897726400, source=0x92a300)
at load.d:423
#8  0x0000002a9576d7c0 in APPLY (n=7231904, fn=0x2a95a26788
<last_result+8>, x=0x2a958dd3c0) at apply.d:24
#9  0x0000002a95736af8 in interpret_funcall (narg=1, fun=0x54e5f0) at
interpreter.d:382
#10 0x0000002a957372a5 in interpret (bytecodes=0x897320,
pc=0x2a958dd3c0) at interpreter.d:664
#11 0x0000002a9573c785 in si_eval_with_env (narg=182897815584,
form=0x78f0a0) at compiler.d:2467
#12 0x0000002a956f983f in L3tpl (narg=7231904) at
ecls-cvs/build/lsp/top.c:142
#13 0x0000002a956f915e in L1top_level () at ecls-cvs/build/lsp/top.c:40
#14 0x0000002a9577965b in APPLY_fixed (n=7231904, fn=0x58cd33,
x=0x2a95a26788) at apply.d:673
#15 0x0000002a95736a98 in interpret_funcall (narg=0, fun=0x6a2e38) at
interpreter.d:380
#16 0x0000002a957372a5 in interpret (bytecodes=0x897410,
pc=0x2a958dd3c0) at interpreter.d:664
#17 0x0000002a9573c785 in si_eval_with_env (narg=182897815584,
form=0x7834c0) at compiler.d:2467
#18 0x0000002a956fd0ba in si_safe_eval (narg=7231904, V1=0x7834c0,
V2=0x2a958dd3c0, V3=0x0)
    at ecls-cvs/build/lsp/top.c:1650
#19 0x0000000000400a4c in main (argc=7231904, argv=0x2a958dd3c0) at
ecls-cvs/build/ECLINITYQ3q6p.c:55

Is there a workaround for this problem?

Michael.