Skip to content

Tag: glibc

NTP 4.2.8p15 fails build with glibc 2.34: error: missing binary operator before token “(“

I am building NTP 4.2.8p15 with glibc 2.34. The build fails with error: Answer The problem is answered here: Since glibc 2.34 PTHREAD_STACK_MIN is no longer a compile time constant so can not be used in preprocessor comparisons which causes the compilation failure [1]. The fix attached to the upstream bug report [2] resolves the issue. Additional info: ntp

getifaddrs returning ‘bad file descriptor’/crashing the application

In my program, I have a thread which has to continuously monitor the network interfaces therefore it continuosly uses getifaddrs() in a while loop. Most of the time my program works fine. However, sometimes getifaddrs() returns -1 and errNo = EBADF(bad file descriptor). In order to not exit my thread, I have temporarily replaced exit with continue(as I don’t want

Building and using a newer GLIBC on CentOS 7

I use CentOS 7 and would like to use some Anaconda python package that requires GLIBC_2.18 while the host OS only provides 2.17. I tried compiling a newer version of glibc myself following these instructions. When I try to run any executable with this newer glibc I am getting an error: Is there a workaround for this issue? Update 1:

Why does link against unexpected location?

I have installed a new glibc in /root/tools/ in debian which already has a pre-installed glibc. For testing the new glibc, I type : produces a.out, then type: it shows But type ls -l /root/tools/lib/ , it shows /root/tools/lib/ -> Why does in new glibc link against in /lib64 ? How to explain this ? Answer then

Installing libc6 2.33 on debian

I would like to install libc6 2.33 onto a debian docker container for security patch reasons. I can see here that it has been released, and also it is noted here that 2.33 is available. Is there any easy way to get this installed onto a debian docker container? Is there a hard way to get this installed onto a

Overlapping mappings for loaded ELF segments

I’d like to understand a detail of how the dynamic loader creates mappings for ELF segments. Consider a tiny shared library linked with GNU ld. The program headers are: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x00095c 0x00095c R E 0x200000 LOAD 0x000df8 0x0000000000200df8 0x0000000000200df8 0x000250 0x000258 RW 0x200000 DYNAMIC 0x000e08 0x0000000000200e08 0x0000000000200e08 0x0001d0 0x0001d0

How does the ELF64 loader know to update the initial addresses in .got.plt?

Consider the following program hello.c: The file is compiled with gcc -o hello -Og -g hello.c and then loaded with gdb hello. Inspecting the GOT for the call to printf with p ‘printf@got.plt’ gives which is the offset of the second instruction in the corresponding PLT entry relative to the start of the section. After starting and linking the program

does linux kill() return after the process excute signal handler?

I want use kill() to kill a program. does linux kernel ensure that the program is killed before kill() returned? If not, I have to check whether the program is killed already. Answer does linux kernel ensure that the program is killed before kill() returned? No, kill merely sends a signal to a process or group of processes. Its successful

Why is the pthread_mutex_t struct all zeros in gdb?

What causes pthread_mutex_t struct to be all zeros? Core of a deadlocked ARM test application in a gdb session: Answer pthread_mutex_t is used for all mutex types and some of its members are only used for specific mutex types. owner member is set for at least the following mutex types: PTHREAD_MUTEX_ERRORCHECK_NP PTHREAD_MUTEX_RECURSIVE_NP See glibc implementation of pthread_mutex_trylock for full more