linker

问题 I'm trying to build a simple ("hello world") C++ program with LLVM/Clang 3.7.0 built from sources against the toolchain's libc++ , with the command line: clang++ -std=c++14 -stdlib=libc++ -fno-exceptions hello.cpp However, I get the following errors: /usr/bin/ld: warning: libc++abi.so.1, needed by /bulk/workbench/llvm/3.7.0 /toolchain4/bin/../lib/libc++.so, not found (try using -rpath or -rpath-link) /bulk/workbench/llvm/3.7.0/toolchain4/bin/../lib/libc++.so: undefined reference to `__cxa

问题 I have a file named main.cpp which includes iostream . I compiled main.cpp and it worked without errors, so my question is: I compiled main.cpp and I did not link iostream with main.cpp , so how could this be possible? Or did the compiler linked the iostream automatically? 回答1: The functions in iostream are part of the C++ standard library, which you usually don't need to link explicitly. If you use a compiler that's not strictly a C++ compiler, you sometimes need to add something like -lstdc

问题 Anyone have idea on this? Linker errors are way out of my wheelhouse, especially ones like this. Is there any more info I should include? 1>Linking... 1>freeglut_static.lib(freeglut_window.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification 1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBCMT.lib(malloc.obj) 1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __recalloc already defined in LIBCMT.lib(recalloc.obj) 1>LIBCMTD.lib(dbgheap.obj)

问题 We came across an unusual phenomenon today, a colleague was calling a normally well-behaved function in his code which was triggering a segfault in libc (gethostbyname). The puzzling thing was that the same function worked without trouble in other source files in the same run-time. Astoundingly, the segfault disappeared when valgrind was used, in fact, it worked perfectly with valgrind, with no errors reported. After much sacrifices to appease the compiler gods we eventually realised that the

问题 I'm playing with function-level linking in VC++. I've enabled /OPT:REF and /OPT:ICF and the linker is happy to eliminate all unused functions. Not so with variables. The following code is to demonstrate the problem only, I fully understand that actually having code structured that way is suboptimal. //A.cpp SomeType variable1; //B.cpp extern SomeType variable1; SomeType variable2; class ClassInB { //actually uses variable1 }; //C.cpp extern SomeType variable2; class ClassInC { //actually uses

问题 I always wondered what is the real use case of __declspec(dllimport) . I know that building a shared library requires to export its symbols using __declspec(dllexport) and then the user of the library use theses symbols as __declspec(dllimport) . Then, you should build your shared library with a special define which enables dllexport and if the flag is not set, the symbols are defined as dllimport . However, I never used dllimport at all and it just works. I have two projects: ImportExport

问题 I am trying to compile my project with an open source library GDCM on Visual C++ 2010 on Windows 7 64 bits. I have included required .lib files (gdcmDSED.lib and gdcmMSFF.lib) in my project, however, the compiler complains back more than 100 unresolved external errors. But I see some patterns in the errors. Here: 1>gdcmDSED.lib(gdcmSequenceOfItems.obj) : warning LNK4049: locally defined symbol ??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ (public: __thiscall std:

问题 If I run gcc a.c -L /usr/lib -lexpat and both libexpat.a and libexpat.so are in /usr lib which one is used by the linker? 回答1: By default the shared library (.so) will be chosen. If you want to change this behavior, -static gcc option may be used -static On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. 来源： https://stackoverflow.com/questions/2545907/gcc-linker-finding-both-so-and-a-in-the-library-path-which

问题 This question has some answers on SO but mine is slightly different. Before marking as duplicate, please give it a shot. MSVC has always provided the /Gy compiler option to enable identical functions to be folded into COMDAT sections. At the same time, the linker also provides the /OPT:ICF option. Is my understanding right that these two options must be used in conjunction? That is, while the former packages functions into COMDAT, the latter eliminates redundant COMDATs. Is that correct? If

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 4 years ago . I try to use the cimg library. I have included the CImg.h-header file. But when I try to compile it, I get a linking error. /tmp/cc2tvYsW.o: In function `cimg_library::cimg::Mutex_info::trylock(unsigned int)': tafelbilder.cpp:(.text._ZN12cimg_library4cimg10Mutex_info7trylockEj[_ZN12cimg_library4cimg10Mutex