MaskRay added a comment. In D136554#4019135 <https://reviews.llvm.org/D136554#4019135>, @rupprecht wrote:
> [...] > The undefined symbols before are all provided by libc++, so those are fine. > After, the new undefined symbol for the lambda cannot be resolved. Depending > on how the linker is invoked, this may or may not be fine -- IIUC the linker > can sometimes recognize that it doesn't actually need the undefined symbol, > so it doesn't matter if it can't find it. > > Here is the build script I'm using, although you will likely need to tweak it > for your own environment: The behavior is expected. For `/tmp/main.o -Wl,--start-lib /tmp/b.o -Wl,--end-lib`, `b.o` is a lazy object file (with archive semantics) which is not extracted. The result is as if the linker discards the input file, so its undefined references do not cause a linker error ([[ https://maskray.me/blog/2021-06-13-dependency-related-linker-options#z-defs | `-z defs` ]]: unresolved undefined non-weak symbol from a relocatable object file; an unextracted lazy file is not considered a relocatable object file ). For `/tmp/main.o /tmp/b.o`, `b.o` is parsed as a relocatable object file. Its undefined reference causes by this patch (experiment locally with `git revert -n 339a7687e1c036a5f91c9d5391523b93e2e76cd3`) leads to a `-z defs` linker error. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136554/new/ https://reviews.llvm.org/D136554 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
