A new fun tracker for a new fun issue. So I'm trying to build packages with global setting of: LDFLAGS="... -Wl,-z,defs" From the manpage: defs Disallows undefined symbols in object files. Undefined symbols in shared libraries are still allowed. also: --no-undefined -z defs Report unresolved symbol references from regular object files. This is done even if the linker is creating a non-symbolic shared library. The switch --[no-]allow-shlib-undefined controls the behaviour for reporting unresolved references found in shared libraries being linked in. In other words, it makes builds fail if shared libraries are using symbols that are not explicitly linked in (normally, those checks are done only on final executables). For example, bug #593670 is about liboctinterp.so using symbols from libz without linking -lz. However, without -Wl,-z,defs the build doesn't fail since the application(s) using liboctinterp.so all happen to link to libz. If you'd like to run crazy checks like this, please note that implicitly linked symbols are sometimes fine, so you'll need to confirm every failure and disable -Wl,-z,defs on packages that rely on this. In particular, most of shared modules (plugins) will fail to build since they rely on the application providing plugin API symbols. It is usually a good idea to convince upstreams to append -Wl,-z,defs to shared libraries whenever supported. For example, LLVM does that, and this allows them to catch such issues early.
--no-allow-shlib-undefined may also be desired. I'm quite lost on the exact meaning, but the error with --no-allow-shlib-undefined are usually more readable.
