From c6f14b3c81f5a40317452625ef8d56c2612fe776 Mon Sep 17 00:00:00 2001 From: Jon Turney Date: Mon, 6 Mar 2017 17:45:40 +0000 Subject: [PATCH] cygwin: Improve discussion of linker library ordering in faq-programming Signed-off-by: Jon Turney --- winsup/doc/faq-programming.xml | 37 +++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/winsup/doc/faq-programming.xml b/winsup/doc/faq-programming.xml index c0ddd7902..65bfed97e 100644 --- a/winsup/doc/faq-programming.xml +++ b/winsup/doc/faq-programming.xml @@ -876,10 +876,45 @@ example, single-stepping from these signals may not work as expected. A common error is to put the library on the command line before the thing that needs things from it. + This is wrong gcc -lstdc++ hello.cc. This is right gcc hello.cc -lstdc++. - + + + The first command above (usually) works on Linux, because: + + A DT_NEEDED tag for libstdc++ is added when the library name is seen. + The executable has unresolved symbols, which can be found in libstdc++. + When executed, the ELF loader resolves those symbols. + + + + + Note that this won't work if the linker flags --as-needed + or --no-undefined are used, or if the library being linked + with is a static library. + + + + PE/COFF executables work very differently, and the dynamic library which + provides a symbol must be fully resolved at link time + (so the library which provides a symbol must follow a reference to it). + + + + See point 3 in for more + discussion of how this affects plugins. + + + + This also has consequences for how weak symbols are resolved. See for more + discussion of that. + + + + Why do I get an error using struct stat64?