libc

This may just be an issue with the build system I am migrating to, but I'll include differences in the two systems and how I encountered the problem. My old build system is a SLES 10 machine. The gcc/cpp/g++ version is 4.1.0 My new system is on SLES 11 SP4, and the gcc/cpp/g++ version is 4.3.4. I am building a shared library; building and linking work fine on the new system. However, at load time on the new system, I get the following: error ./mysharedlib.so: undefined symbol: stat Since the stat() function is included from /usr/include/sys/stat.h, I looked at glibc on both systems. Old: # rpm

So, I find myself in the need of libc in my C++ program. However, I do not like the idea of sprinkling it all over the global namespace. Ideally, I'd like to force the entirety of libc into the std:: namespace so I'd have to do std::memcpy rather than memcpy . Is this possible? And how? I'm willing to use compiler-specific macros if needed (I target only MS VC++ 10.0 and GCC 4.6). Edit: I do literally mean 'force the declarations into std' - so that they are uncallable without the std:: prefix. Also, I am including cstdio , not stdio.h . Thanks! You cannot do this, unless it's already done.

I'm trying to intercept the openat() system call on Linux using a custom shared library that I can load via LD_PRELOAD . An example intercept-openat.c has this content: #define _GNU_SOURCE #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> #include <dlfcn.h> int (*_original_openat)(int dirfd, const char *pathname, int flags, mode_t mode); void init(void) __attribute__((constructor)); int openat(int dirfd, const char *pathname, int flags, mode_t mode); void init(void) { _original_openat = (int (*)(int, const char *, int, mode_t)) dlsym(RTLD_NEXT, "openat"); }

glibc and eglibc have a PTR_MANGLE , which encrypts pointers in writable memory (more correctly, 'XOR' rather than 'encrypt'). I'm not finding much reading on the feature. man -k PTR_MANGLE returns no hits, and Google is returning some superficial chatter. One of the few definitive articles is Drepper's Pointer Encryption on Live Journal. Is there any in-depth documentation on it? Can it be extended into the user space process, or is it limited to the runtime library? If so, what is the compiler switch or option to enable the feature? Can the feature be disabled in the runtime? PTR_MANGLE is

I am working in glibc and I need to get the id of the current thread. For this i use syscall(SYS_gettid); Issue is, i am forced to include bits/syscall.h instead of ideal case i.e sys/syscall.h . sys/syscall.h internally calls bits/syscall.h but that is wrapped with #ifndef _LIBC macro. i.e #ifndef _LIBC /* The Linux kernel header file defines macros `__NR_<name>', but some programs expect the traditional form `SYS_<name>'. So in building libc we scan the kernel's list and produce <bits/syscall.h> with macros for all the `SYS_' names. */ # include <bits/syscall.h> #endif also bits/syscall.h

Let's have a look at this Hello World program #include <stdio.h> int main(int argc, char ** argv) { printf("Hello, World!"); const char* sFile = "/dev/stdout"; // or /proc/self/fd/0 const char* sMode = "w"; FILE * output = fopen(sFile, sMode); //fflush(stdout) /* forces `correct` order */ putc('!', output); // Use output or stdout from stdio.h return 0; } When compiled using the output file descriptor the output is: !Hello, World! when compiled using the stdout file descriptor provided by stdio.h the output is as expected: Hello, World!! I figure when calling putc with the latter, it will

I'm trying to use sprof to profile some software (ossim) where almost all the code is in a shared library. I've generated a profiling file, but when I run sprof, I get the following error: > sprof /home/eca7215/usr/lib/libossim.so.1 libossim.so.1.profile -p > log Inconsistency detected by ld.so: dl-open.c: 612: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed! The instructions I was following said that I needed libc version at least 2.5-34, I have libc version 2.12.2 (Gentoo, kernel 2.6.36-r5). I can't find any explanation as to what the error means or

I'm trying to find info and I don't see it on clang web site. I'm thinking to try to use it on windows, but I have no clue if it has it's own libc or it uses broken libc from MS? another question: if i compile code with clang, will I be able to use visual studio as a debugger, e.g. is clang capable of emitting debugging symbols in MS format (this is the reason I don't want to use gcc; and this is something that intel compiler can do, but it uses MS's libc). In short, I'd like to be able to use visual studio as a debugger, but I need at the same time decent real c compiler with normal lib c. or