[Ecls-list] Missing symbols when embedding a static lib into a FAS file
Juan Jose Garcia Ripoll
lisp at arrakis.es
Tue Mar 14 08:24:08 UTC 2006
On Mon, 2006-03-13 at 14:15 +0100, Goffioul Michael wrote:
> 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)
> Is there a workaround for this problem?
Would this be solved if you join steps 1) and 2) ? I mean passing the
list of object files to build-fasl instead of the library.
I suspect this is not a solution. I remember that this change was
introduced by Maciek to solve some name collisions in Linux, as shown in
the log:
revision 1.79
date: 2005/05/26 22:46:34; author: japhie; state: Exp; lines: +6 -3
When linking a fasl, find individual objects' entry function in the
same fasl only by ecl_library_symbol instead of relying on dynamic
linker (avoids filename/entry-function-name conflicts).
But now I have problems remembering what caused these conflicts.
Probably similar function names from different FASL files and the
current dll pulling the name out of a different FASL when one compiles
direct calls. Maybe he can remind us :-)
Regards,
Juanjo
More information about the ecl-devel
mailing list