The short answer is no - ECL links against the libc present on the system. It is not that it could not be improved in this regard. Even when you compile with "

The short answer is no - ECL links against the libc present on the system. It is not that it could not be improved in this regard. Even when you compile with "--disable-shared" you'll link against libc (but everything else will be statically linked). The function "--disable-shared" does not remove the compiler to native, it removes compilation of fasls to native. The reason for that is this: - "native" fasls are shared objects under disguise linked against libecl (dlopen) - they can't not link against libecl unless you want to statically link whole ecl with the fasl Imagine that you call a PRINT function from the FASL. The symbol you will probably reference is ecl_print that is defined in ECL core runtime (usually in libecl.so, libecl.a/static-ecl). The native compiler still can produce statically linked native binaries. Now I'll get into current ECL developments - mind that this is not granted that this pan out as expected - perhaps I'll scrap whole work at some point: I'm refactoring ECL compiler to have multiple frontends and backends (something like LLVM) - currently passes are far more coupled. With that I hope to have a better control over a generated code and we could use static analysis about which parts of CL are used, and in an opt-in manner we could allow minimal static builds that do not depend on full CL. Such static binaries could be really small.