Problem:
The linker currently expects all functions imported by one of the modules linked together to be exported by another module, otherwise it fails. This works well for linking together a final binary module, but does not allow for linking partially-linked modules, which have still unresolved import linkages.

Use-case:
I have an OpenCL compiler, that uses the SPIRV-Tools to read SPIR-V input, link SPIR-V modules if necessary, and convert it into an internal representation. In the device-side standard-library (which is linked into the kernel code) I also define some additional intrinsic functions to access special hardware components (like mutex, semaphores, etc.). These functions are then replaced by my compiler with the corresponding hardware-instructions and therefore not defined in any SPIR-V module. This works fine with a single SPIR-V module, since imported functions are accepted by SPIRV-Tools, but not when linking modules, since the linker does not allow for any functions to remain imported. See also here for a discussion on this.

Solution:
Allow the linker to create "partially linked" modules by not throwing errors when there is no exported symbol matching an imported one, instead it should leave the imported symbol as such. Since this behaviour may not always be intended, it should be added as optional feature, e.g. as a new flag to spvtools::LinkerOptions.