cross compilation and LOAD-FOREIGN-LIBRARY

[Attila Lendvai]

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://common-lisp.net/project/ecl/posts/ECL-Quarterly-Volume-IV.html

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-LIBRARY breaks loading, even though none of the FFI definitions get exercised.

currently it's widespread practice to add a toplevel CFFI:DEFINE-FOREIGN-LIBRARY immediately followed by a CFFI:USE-FOREIGN-LIBRARY.

what would be an advisable practice to avoid these issues?

[Attila Lendvai (attila-lendvai)]

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.

[Luís Oliveira (luismbo)]

For ECL, we could probably detect that cross-compilation is going on and suppress library loading there. Maybe?

Problematic situation #2 seems trickier. As you mentioned, SBCL wants the foreign function to be available at compiler/load time. Perhaps we can add an ignore restart to the load-foreign-library error?