libc

I'm using Ubuntu 14.04.2 LTS \n \l . Here are the libc s I installed. $ dpkg --list | grep libc6 ii libc6:amd64 2.19-0ubuntu6.7 amd64 Embedded GNU C Library: Shared libraries ii libc6-dbg:amd64 2.19-0ubuntu6.7 amd64 Embedded GNU C Library: detached debugging symbols ii libc6-dev:amd64 2.19-0ubuntu6.7 amd64 Embedded GNU C Library: Development Libraries and Header Files ii libc6-i386 2.19-0ubuntu6.7 amd64 Embedded GNU C Library: 32-bit shared libraries for AMD64 rc libc6-x32 2.19-0ubuntu6.7 amd64 Embedded GNU C Library: X32 ABI Shared libraries for AMD64 But when I do $ sudo apt-get install

I'm trying to implement a simple fit first memory management algorithm. So I've got a C file with my own void* malloc(size_t) and void free(void*) When generating a .out file with gcc, I'm expecting a link error because it'll conflict with the existing standard implementation. But my file links fine. Please help me to understand. I'm expecting a link error because it'll conflict with the existing standard implementation. Your expectation is incorrect: most UNIX libc implementations support using some other malloc. To that end, they put malloc , realloc , free etc. either into a separate object

I have been cross-compiling some Linux tools (and some of my own C code) to Android and one of the challenges that I face is that Android's libc has some missing/stripped components and I end up patching my code to make it work with Android's libc (for e.g. a problem like this http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html ) Q1 : How do I go about statically linking against glibc (and other dependencies) while cross-compiling with the arm toolchain (or ndk-build)? Q2 : Is it a good idea to statically link against glibc for binaries for Android? Should I expect

The gets function was first deprecated in C99 and finally removed in C11. Yet there is no direct replacement for it in the C library. fgets() is not a drop-in replacement because it does not strip the final '\n' , which may be absent at the end of file. Many programmers get it wrong too. There is a one-liner to remove the linefeed: buf[strcspn(buf, "\n")] = '\0'; , but it is non-trivial and often calls for an explanation. It may be inefficient as well. This is counter-productive. Many beginners still use gets() because their teachers are lame or their tutorials obsolete. Microsoft proposed

I installed Matlab in my Linux Mint 14 Nadia (a uname -a shows: Linux Ideapad-Z570 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) and when calling it from the command line I would get a: "/lib64/libc.so not found". I followed the help on mathworks by making a link in /lib64 as: ln -s /lib/x86_64-linux-gnu/libc.so.6 . That solved the issue. Now, if I do a locate of this library I get: locate "libc.so" /lib/i386-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so I will be compiling with gcc in this computer and I

On my system (Mac OS 10.6) /usr/include/stdarg.h is: /* This file is public domain. */ /* GCC uses its own copy of this header */ #if defined(__GNUC__) #include_next <stdarg.h> #elif defined(__MWERKS__) #include "mw_stdarg.h" #else #error "This header only supports __MWERKS__." #endif So, if GCC uses its own copy of stdarg.h , where is it? I have no idea on what that #include_next means (maybe a GCC extension?), nor something about "MWERKS" (a compiler?). <stdarg.h> , even more than most C library headers, tends to be very compiler-specific. As such, each of the compilers on OS X has it's own