[CentOS] static linking
Hello, Can someone explain why a static library would make calls to dlopen? openssl-static-1.0.1e-48.el6_8.3.x86_64 /usr/lib64/libcrypto.a In trying to staticly link against the above I get /usr/lib64/libcrypto.a(fips.o): In function `verify_checksums': (.text+0x62b): undefined reference to `dlopen' It didn't use to do this. Thanks, Steve ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Static Linking, C++ Exceptions
I'm having a problem statically linking a big c++ application on Centos4. I can make it work on Centos5 and that's great. I just need to figure out a way to reproduce the problem on a small test case. The specific problem is that when I throw an exception, I get a segfault. It only happens on Centos4, and only on ia-32 machines. In an act of desparation I disassembled the bit of code that's segfaulting and got this: (gdb) disass Dump of assembler code for function _ZN14__gnu_internal10get_globalEv: 0x08579614 <...get_globalEv+0>: call 0x8577c3e <__i686.get_pc_thunk.cx> 0x08579619 <...get_globalEv+5>: add$0x3b31c7,%ecx 0x0857961f <...get_globalEv+11>:push %ebp 0x08579620 <...get_globalEv+12>:mov$0xfff8,%eax 0x08579626 <...get_globalEv+18>:mov%esp,%ebp 0x08579628 <...get_globalEv+20>:pop%ebp 0x08579629 <...get_globalEv+21>:add%gs:0x0,%eax <<<--- dies here! <<< 0x08579630 <...get_globalEv+28>:ret 0x08579631 <...get_globalEv+29>:nop End of assembler dump. When it dies, %gs is 0 which looks tls related. Only problem is that when I write tiny test programs to reproduce this, they work fine. %gs is nonzero and everybody is happy. But on my big hulking app, I can throw and catch an exception immediately on entry to main and it segfaults faithfully. Relevant compiler flags are these: g++ -c -o whatever.o -O0 -ggdb -Wno-deprecated -Werror -fPIC -Dmanything -Imanydirs whatever.cpp g++ -o whatever -static -static-libgcc many.o -Lmanydirs -lpthread -lanotherlib -lzlib -lesmtp -lnsl -lrpcsvc -lcrypt -lacl -ldl -lrt -landmanymore So I'm looking for some guidance on what things I could try to isolate this in a smaller app. -- Darrin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Static linking against glibc
I'm building an RPM of a DNS server called NSD on CentOS 4.4. I'm going to be using it for some heavy-duty DNS traffic, so I want to minimise its dependencies on external libraries. I have therefore attempted to link it statically. The package does build, and even runs fine. However, during the build process, gcc emits warnings like these: nsd.o(.text+0xfba): In function `main': : warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking My understanding of this is because glibc uses dlopen to load other shared objects at runtime. I therefore need a Requires: line in the RPM which requires glibc-2.3.4-2.36, or whatever version I used to build nsd. Now, what I want to ask is: if the version of glibc is upgraded to say 2.3.4-2.48, what happens? What do the numbers after the version number mean (2.48) and what effect will that have on packages which are statically linked against glibc? Another question which has occured to me is this: NSD also uses other libraries, such as openssl. Is there any way to know if any of the openssl libraries use dlopen to load in other shared objects? If they do, then it introduces dependencies that I may not be aware of, and doing static linking wouldn't be as beneficial as I first thought it would be. Comments from experienced developers will be most appreciated. -- Anand Buddhdev ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
