On Thu, Nov 29, 2018 at 23:45:18 +0300, Roman Bolshakov wrote: > On Thu, Oct 25, 2018 at 01:20:57PM -0400, Emilio G. Cota wrote: > > + > > +lib%.so: %.o > > + $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) > > The rule should be a bit different for macOS: > %.bundle: %.o > $(CC) -bundle -Wl,-bundle_loader,PATH_TO_QEMU_EXE -o $@ $^ $(LDLIBS) > > "-bundle" flag is needed because macOS has two kinds of Mach-O > dynamically loaded executables: > - dylib (MH_DYLIB) - it's like an ELF shared object used for dynamic > linking. Can be loaded, preloaded for sake of function interposing > but cannot be explicitly unloaded. > - bundle (MH_BUNDLE) - similar to an ELF shared object used in plugin > dlopen/dlclose scenario. > > We can pick any (enabled in configure) qemu-system executable as > bundle_loader. We specify it to check if all symbols in a bundle, > including the ones coming from the executable are defined. FWIW, here's > the reference for bundle_loader flag: > -bundle_loader executable > This specifies the executable that will be loading the bundle > output file being linked. Undefined symbols from the bundle are > checked against the specified executable like it was one of the > dynamic libraries the bundle was linked with > > > The ".bundle" extension is not required but IMO it feels more native to > the system than ".so".
The goal of the examples is to be target-independent, so I'm not convinced that we want to bury $PATH_TO_QEMU_EXE in the build recipe (or get configure involved in this). Since you say the "bundle" business isn't a requirement, I'll leave just the .so rule in v2. Thanks, Emilio