cross compilation and LOAD-FOREIGN-LIBRARY
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
CFFI |
New
|
Undecided
|
Unassigned |
Bug Description
problematic situation 1:
when ECL is cross compiling, then the resulting fasl (a binary compiled from generated C code) cannot be loaded on the host.
details: https:/
problematic situation 2:
Xach is running his integration tests for quicklisp on a throwaway virtual machine to test whether projects and their dependencies at least load successfully. if this virtual machine doesn't have the necessary .so's installed, then an unconditional toplevel LOAD-FOREIGN-
currently it's widespread practice to add a toplevel CFFI:DEFINE-
what would be an advisable practice to avoid these issues?
maybe CFFI:USE- FOREIGN- LIBRARY should not be at toplevel, but rather in the startup code of the apps? if so, then it should be documented.
a slight annoyance with that would be that some lisps (IIRC e.g. SBCL) spit out a lot of warnings when the underlying dlsym is not available at the time of the loading (or also at compilation?) of the DEFCFUN.
or maybe CFFI could add some smarts that transparently delays dlopen? e.g. a one-time initialization code delayed until the first use? this would bring in some concurrency headaches, though.