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/ld-linux-x86-64.so.2 , it shows /root/tools/lib/ld-linux-x86-64.so.2 -> ld-2.33.so Why does ld.so in new glibc link against ld.so in /lib64 ? How to explain this ? Answer then
Tag: gcc
GCC promotes weird relocation R_X86_64_32S error but not in manually linking
I’m trying to invoke sys_write via the syscall instruction under Linux environment on an x86_64 machine with inline assembly in C files. To achieve this, I wrote the following code: While my compiling it with GCC, the following error promoted: Then I added -fPIE to the compiler command. Unfortunately, nothing changed: This is so weird that it made me curious
Why tm_gmtoff field of struct tm is not documented in man page?
I need to get the difference between UTC and the local time using GCC on Linux. It seems that the preferred way is to examine tm_gmtoff field of a struct tm returned by localtime function. https://stackoverflow.com/a/47218792 However, tm_gmtoff is not documented in the man page of localtime, but only tm_zone is. https://man7.org/linux/man-pages/man3/localtime.3.html It looks like tm_gmtoff and tm_zone exist in
How to show gcc compiler warnings in VSCode terminal of a .c file
I have the C/C++ ms-vscode.cpptools extension installed (and the Code Runner). This is my task.json Note the -Wall option in the args part. When I compile and run the code the warnings don’t show up in my terminal, the errors only. Am I missing something? Answer Solved it was the configuration of code runner to be edited as well. Now
will cmake build type RelWithDebInfo strip symbol table?
I was building a shared library using cmake with RelWithDebInfo build type, the output .so file has no symbol table. I inspect the output .so file with readelf -S myoutput.so | grep -i debug with gives me nothing. If I change the build type to Debug, the symbol table is there. I suppose RelWithDebInfo is equivalent to -O2 -g, which
Segmentation fault when executed from linux command line [closed]
Closed. This question needs debugging details. It is not currently accepting answers. Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question. Closed 1 year ago. Improve this question My code compiles and runs fine in my IDE. However, when I use
Why doesn’t defining `__cxa_throw` cause a link error?
Why doesn’t the following C++ program have a link conflict with the system-provided __cxa_throw ? Is there something magical about that symbol? For a normal function this would be an ODR violation wouldn’t it? Answer As @Igor pointed out, you need to add extern “C” to prevent name mangling. But the cause why it works is because the symbol is
Embedded python fails to compile on Raspberry Pi
I installed python 3.9.1 on my Raspberry Pi following the instructions here https://www.ramoonus.nl/2020/10/06/how-to-install-python-3-9-on-raspberry-pi/ and set it as the default python interpreter. I got my compiling and linking parameters for embedded Python following the instructions here https://docs.python.org/3.9/extending/embedding.html#compiling-and-linking-under-unix-like-systems I tried a simple test with the following code (test.c) : and then gcc -I/usr/local/opt/python-3.9.1/include/python3.9 -I/usr/local/opt/python-3.9.1/include/python3.9 -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -c
How can I ask GCC to use a different standard library?
I have a debug version of libstdc++ 6 in /usr/lib/debug/usr/lib/x86_64-linux-gnu/. I would like to tell gcc/g++ to use this library instead of the standard library version without debug symbols. I tried using -nostdlib and passing the library path explicitly with -L, but get linking errors such as It seems that the library version (according to the file name) is the
GCC not added to system path on pacman install
Issue When installing mingw on a fresh MSYS2 instance I run into the issue of gcc not found: Setup Fresh MSYS2 install on relatively clean windows 10 install: Diagnostics It appears that GCC is successfully installed into the directory /mingw64/bin Yet my path consists of As such gcc is not found. I have tried adding /mingw64/bin to the $PATH however