static-linking

I am trying to create a static executable with Rust. I am not trying to statically link a particular library, I am trying to create a executable which does not use dynamic linking at all . I have the following (otherwise working) test: $ cat hello.rs fn main() { print!("Hello, world!\n"); } $ rustc hello.rs -o hello $ file hello hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, [etc] Note the dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 . Static executables have statically linked instead. (And in my case

This may be a Visual Studio question more than anything else... I'm trying to build a 0MQ C++ example using VS10 and ZeroMQ 2.2.0. I downloaded the windows sources and tried to follow these instructions in order to build 0MQ statically. Specifically: Switched to Release For all 7 projects in the solution: set General\Configuration Type to Static library (.lib) set C/C++\Code Generation\Runtime Library to Multi-threaded (/MT) added ZMQ_STATIC to C/C++\Preprocessor\Preprocessor Definitions Updated zmq.h and zmq_utils.h so that if _MSC_VER and ZMQ_STATIC are defined then DLL_EXPORT will also be

This is the first time I am asking on stackoverflow and I am desperate. My task is to load a dylib or join a static lib to an already existing executable for an IOS device. I will be using the static void __attribute__((constructor)) initialize(void) to start the swizzling. This executable is for in house enterprise appstore so i do not need to go thru the apple appstore (since they will reject it). The reason for this is to take an existing IPA from a customer and their signing keys and add a new functionality to their application without requiring a developer intervention. There is one

I'm trying to compile a statically linked binary with GCC and I'm getting warning messages like: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I don't even know what getwnam_r does, but I assume it's getting called from inside some higher level API. I receive a similar message for gethostbyname . Why would it not be possible to just statically link these functions in like every other function? Function calls that need access to NSS or iconv need access will open other libs dynamically , since NSS

I try to link libraries in my program using firebreath framework. So I add this code in projectDef.cmake. include_directories(/usr/include/giblib) include_directories(/usr/include/X11) add_library(giblib_ptm STATIC IMPORTED) set_property(TARGET giblib_ptm PROPERTY IMPORTED_LOCATION /usr/lib/libgiblib.a) add_library(X11_ptm STATIC IMPORTED) set_property(TARGET X11_ptm PROPERTY IMPORTED_LOCATION /usr/lib/i386-linux-gnu/libX11.a) add_library(Imlib_ptm STATIC IMPORTED) set_property(TARGET Imlib_ptm PROPERTY IMPORTED_LOCATION /usr/lib/libImlib2.a) target_link_libraries(Printmade2 giblib_ptm X11_ptm

I have to make a dso that static link stdc++ and need can unload from memory dynamic. So I tried with compile gcc with --disable-gnu-unique-object and use gold link with -Wl,--no-gnu-unique options. But both contains memory leak issue even I do nothing except call dlopen() dlclose() in main. The test code like: int main() { for(int i=0;i<1000;i++) { void * h=dlopen(filepath); if(h) dlclose(h); } return 0; } Than I checked the memory cat /proc/pid/maps before and after I found only heap changes bigger and bigger every time. About 90M after 1000 time call dlopen & dlclose to me 90M is still too

Using visual studio 2008, I have an .H and a .LIB file of a library. I wrote a program and referenced the LIB via the project properties. It compiles fine, but when it runs, it asks for the DLL to be installed. If the DLL is in the same dir as the EXE it works but, if I have the LIB , doesn't it already mean the functions are statically linked to my program? Not all lib files are static libraries. Some are import libraries, and chances are, that's what you linked with. If your lib file is much smaller than its corresponding dll file, that's a sure sign that it's an import library. Letting your