I am trying to build a program in C which has a lot of optional features that depend on various shared libraries.
In our heterogeneous computing cluster not all of those libraries are available (or up to date) on all systems.
Examples are symbols from newer glibc (sched_getcpu##GLIBC_2.6, __sched_cpucount##GLIBC_2.6) or whole shared libraries which may or may not be available (libnuma, libR, libpbs).
I know that I can use libdl to load the symbols with dlopen and dlsym, but doing this for an ever growing number of symbols (around 30 at the moment) is tedious at best.
As far as I understand shared libraries in Linux are lazy-loaded by default, so a symbol should not be needed until it is actually used.
But if I try to check for that in advance then it fails at execution start:
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <dlfcn.h>
#include <sched.h>
int main() {
void *lib_handle;
int (*fn)(void);
int x;
char *error;
lib_handle = dlopen("libc.so.6", RTLD_LAZY);
if (!lib_handle)
{
fprintf(stderr, "%s\n", dlerror());
exit(1);
}
fn = dlsym(lib_handle, "sched_getcpu");
if ((error = dlerror()) != NULL)
{
fprintf(stderr, "%s\n", error);
exit(1);
}
printf("%d\n", sched_getcpu());
return 0;
}
On compile system which has all libraries:
$ icc test.c
$ ./a.out
10
On another system which has a less recent version of GLIBC:
$ ./a.out
./a.out: /lib64/libc.so.6: version `GLIBC_2.6' not found (required by ./a.out)
If I comment out the line that actually calls sched_getcpu then I get instead on the lesser system:
$ ./a.out
/lib64/libc.so.6: undefined symbol: sched_getcpu
So, is there a way to force libraries only to be loaded on use and have checks like these before blocks that use them?
Not with glibc. This is a fail-safe and it's in place so that you won't shoot yourself in the foot. If the GLIBC_2.6 symbol wasn't defined and looked up, even if there were no other missing symbols, you could get garbage results from glibc (data corruption and crashes,) since it's not forwards compatible.
If you need compatibility on the glibc level, you need to build against the lowest common version.
Related
So everyone probably knows that glibc's /lib/libc.so.6 can be executed in the shell like a normal executable in which cases it prints its version information and exits. This is done via defining an entry point in the .so. For some cases it could be interesting to use this for other projects too. Unfortunately, the low-level entry point you can set by ld's -e option is a bit too low-level: the dynamic loader is not available so you cannot call any proper library functions. glibc for this reason implements the write() system call via a naked system call in this entry point.
My question now is, can anyone think of a nice way how one could bootstrap a full dynamic linker from that entry point so that one could access functions from other .so's?
Update 2: see Andrew G Morgan's slightly more complicated solution which does work for any GLIBC (that solution is also used in libc.so.6 itself (since forever), which is why you can run it as ./libc.so.6 (it prints version info when invoked that way)).
Update 1: this no longer works with newer GLIBC versions:
./a.out: error while loading shared libraries: ./pie.so: cannot dynamically load position-independent executable
Original answer from 2009:
Building your shared library with -pie option appears to give you everything you want:
/* pie.c */
#include <stdio.h>
int foo()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return 42;
}
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
/* main.c */
#include <stdio.h>
extern int foo(void);
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so
$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$
P.S. glibc implements write(3) via system call because it doesn't have anywhere else to call (it is the lowest level already). This has nothing to do with being able to execute libc.so.6.
I have been looking to add support for this to pam_cap.so, and found this question. As #EmployedRussian notes in a follow-up to their own post, the accepted answer stopped working at some point. It took a while to figure out how to make this work again, so here is a worked example.
This worked example involves 5 files to show how things work with some corresponding tests.
First, consider this trivial program (call it empty.c):
int main(int argc, char **argv) { return 0; }
Compiling it, we can see how it resolves the dynamic symbols on my system as follows:
$ gcc -o empty empty.c
$ objcopy --dump-section .interp=/dev/stdout empty ; echo
/lib64/ld-linux-x86-64.so.2
$ DL_LOADER=/lib64/ld-linux-x86-64.so.2
That last line sets a shell variable for use later.
Here are the two files that build my example shared library:
/* multi.h */
void multi_main(void);
void multi(const char *caller);
and
/* multi.c */
#include <stdio.h>
#include <stdlib.h>
#include "multi.h"
void multi(const char *caller) {
printf("called from %s\n", caller);
}
__attribute__((force_align_arg_pointer))
void multi_main(void) {
multi(__FILE__);
exit(42);
}
const char dl_loader[] __attribute__((section(".interp"))) =
DL_LOADER ;
(Update 2021-11-13: The forced alignment is to help __i386__ code be SSE compatible - without it we get hard to debug glibc SIGSEGV crashes.)
We can compile and run it as follows:
$ gcc -fPIC -shared -o multi.so -DDL_LOADER="\"${DL_LOADER}\"" multi.c -Wl,-e,multi_main
$ ./multi.so
called from multi.c
$ echo $?
42
So, this is a .so that can be executed as a stand alone binary. Next, we validate that it can be loaded as shared object.
/* opener.c */
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
void *handle = dlopen("./multi.so", RTLD_NOW);
if (handle == NULL) {
perror("no multi.so load");
exit(1);
}
void (*multi)(const char *) = dlsym(handle, "multi");
multi(__FILE__);
}
That is we dynamically load the shared-object and run a function from it:
$ gcc -o opener opener.c -ldl
$ ./opener
called from opener.c
Finally, we link against this shared object:
/* main.c */
#include "multi.h"
int main(int argc, char **argv) {
multi(__FILE__);
}
Where we compile and run it as follows:
$ gcc main.c -o main multi.so
$ LD_LIBRARY_PATH=./ ./main
called from main.c
(Note, because multi.so isn't in a standard system library location, we need to override where the runtime looks for the shared object file with the LD_LIBRARY_PATH environment variable.)
I suppose you'd have your ld -e point to an entry point which would then use the dlopen() family of functions to find and bootstrap the rest of the dynamic linker. Of course you'd have to ensure that dlopen() itself was either statically linked or you might have to implement enough of your own linker stub to get at it (using system call interfaces such as mmap() just as libc itself is doing.
None of that sounds "nice" to me. In fact just the thought of reading the glibc sources (and the ld-linux source code, as one example) enough to assess the size of the job sounds pretty hoary to me. It might also be a portability nightmare. There may be major differences between how Linux implements ld-linux and how the linkages are done under OpenSolaris, FreeBSD, and so on. (I don't know).
I load a symbol from a shared library like this:
void *sym = dlsym(RTLD_DEFAULT, "printf");
That will tell me whether the symbol printf exists in a loaded shared library, and if it does, what its address is, but it will not tell me which shared library it was loaded from. Is there a way to determine that?
Note I want to find the answer programatically at runtime, so solutions using debuggers, the LD_DEBUG environment variable, etc., are not what I am looking for.
I am particularly looking for solutions for Linux and macOS.
Here's an example of how to do this with the dladdr function:
#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
void show_sym(const char *sym_name) {
void *sym_ptr = dlsym(RTLD_DEFAULT,sym_name);
printf("SYMBOL %s ADDRESS %p\n", sym_name, sym_ptr);
if (sym_ptr == NULL)
return;
Dl_info info;
int rc = dladdr(sym_ptr,&info);
assert(rc != 0);
printf("SHARED LIBRARY NAME: %s\n", info.dli_fname);
printf("SHARED LIBRARY BASE ADDRESS: %p\n", info.dli_fbase);
printf("NEAREST SYMBOL: %s\n", info.dli_sname);
printf("NEAREST SYMBOL ADDRESS: %p\n", info.dli_saddr);
}
int main(int argc, char** argv) {
if (argc != 2) {
fprintf(stderr,"usage: %s SYMBOL-NAME\n", argv[0]);
return 1;
}
show_sym(argv[1]);
return 0;
}
I tested the above code and it works on both macOS and Linux. (On Linux you have to link against -ldl.) Although I haven't tested it, the same (or similar) code likely works on other Unix-like platforms which implement dladdr, such as Solaris (which is where dladdr comes from originally), FreeBSD, OpenBSD, NetBSD, DragonFly BSD, HP/UX. (And the IBM mainframe operating system z/TPF too, which few would call "Unix-like".)
It is possible to do the same thing on Windows, but the API is completely different (basically turn the address into a HMODULE using GetModuleHandleEx and then call GetModuleFileName). There are some other Unix-likes which support this but not using the dladdr API, e.g. AIX lacks dladdr but has an API loadquery which reports at what memory addresses shared libraries are loaded and so can be indirectly used to work this out (indeed, here is some sample code to do that, although I haven't tested that code myself.)
I am digging deeper into system calls,
Added a system call into both syscall_32.tbl and syscall_64.tbl
syscall_32.tbl
434 i386 hello sys_hello __ia32_sys_hello
syscall_64.tbl
434 common hello __x64_sys_hello
Definition:
SYSCALL_DEFINE0(hello) {
pr_info("%s\n", __func__);
pr_info("Hello, world!\n");
return 0;
}
User space code:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/syscall.h>
#include <string.h>
int main(void)
{
long return_value = syscall(434);
printf("return value from syscall: %ld, erron:%d\n", return_value, errno);
return 0;
}
When i run this user space code on x86_64, i get the following output in dmesg
$ gcc userspace.c -o userspace
[ 800.837360] __x64_sys_hello
[ 800.837361] Hello, world!
But when i compile it for 32-bit, i get
$ gcc userspace.c -o userspace -m32
[ 838.979286] __x64_sys_hello
[ 838.979286] Hello, world!
How come the entry point present in syscall_32.tbl (__ia32_sys_hello) maps to __x64_sys_hello?
On a 64-bit kernel, SYSCALL_DEFINE0 defines the compat (32-bit) and other ABI (e.g. x32 on x86_64) syscall entry points as aliases for the real 64-bit function. It does not define (and has no way to define; that's not how the preprocessor works) multiple functions built from a single body appearing after the ) of the macro evaluation. So __func__ expands to the name of the actual function that has __func__ written in it, not the name of the alias.
For SYSCALL_DEFINEx with x>0, it's more complicated since arguments have to be converted, and I believe wrappers are involved.
You can find all the magic in arch/x86/include/asm/syscall_wrapper.h (under the top-level kernel tree).
If you really want/need there to be separate functions, I believe there's a way to skip the magic and do it. But it makes your code harder to maintain since it may break when the mechanisms behind the magic break. It's likely preferable to probe whether the calling (current) userspace process is 32-bit or 64-bit and act differently according to that.
I'm running OS X Sierra and trying to compile a c program that uses strcpy_s, but my installed clang compiler is using the c99 standard, but from what I've read strcpy_s requires c11.
Here's the code I'm trying to compile
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
char source[] = "Test string";
char destination[50];
if(strcpy_s(destination, sizeof(destination), source))
printf("string copied - %s",destination);
return 0;
}
And here's the command I'm using to compile
$ clang copytest.c -o copytest
copytest.c:11:5: warning: implicit declaration of function 'strcpy_s' is invalid in C99 [-Wimplicit-function-declaration]
if(strcpy_s(copied_string, sizeof(copied_string), source))
^
1 warning generated.
Undefined symbols for architecture x86_64:
"_strcpy_s", referenced from:
_main in copytest-e1e05a.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've tried compiling with the standard flag...
clang -std=c11 copytest.c -o copytest
but I get the same exact "invalid in c99" warning. I've also tried compiling with gcc instead, and I still get the same c99 warning.
I tried upgrading via homebrew which shows the following
Warning: gcc 9.2.0 is already installed and up-to-date
I have clang version 9.0.0
$ clang -v
Apple LLVM version 9.0.0 (clang-900.0.39.2)
My xcode version is Xcode 9.2, which from everything I've read should come with c11 support.
Am I doing something wrong with the compiling, is my code itself incorrect? This is the only similar question I found on here, but it didn't even have an answer. Thanks
The _s functions are an optional component of the 2011 C standard (Annex K), and, to the best of my knowledge, they have never been implemented as an integrated part of any C library. Portable code cannot rely on their availability. (Microsoft's C compilers for Windows implement an overlapping set of functions with the same names but different semantics (and sometimes even a different argument list), and at least one bolt-on implementation does exist. See this old answer, and the much longer question and answer it links to, for more detail.)
Also, the _s functions do not solve the problem that they were intended to solve (unsafe string handling); it is necessary to put actual thought into a proper fix for each use of strcpy, instead of globally search-and-replacing strcpy with strcpy_s, etc., as was the hope of the authors of Annex K. If you do put appropriate amounts of thought into a proper fix, you won't need any of the _s functions to implement it. For instance, here's a fixed version of your example program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
char source[] = "Test string";
char destination[50];
size_t srclen = strlen(source);
if (srclen + 1 > sizeof destination) {
fprintf(stderr, "string too long to copy - %zu bytes, need %zu\n",
sizeof destination, srclen + 1);
return 1;
} else {
memcpy(destination, source, srclen + 1);
printf("string copied - %s\n", destination);
return 0;
}
}
And here's an even better version:
#define _XOPEN_SOURCE 700
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
if (argc != 2) {
fprintf(stderr, "usage: ./test 'message of arbitrary length'\n");
return 1;
}
char *destination = strdup(argv[1]);
if (!destination) {
perror("strdup");
return 1;
}
printf("string copied - '%s'\n", destination);
free(destination);
return 0;
}
Therefore: Never use any of the _s functions. If you need to write a program that compiles on Windows with no warnings, put #define _CRT_SECURE_NO_WARNINGS 1 at the top of each file to make MSVC stop giving you bad advice.
If all, or even most, programmers wrote the suggested solutions above all the time, then these functions wouldn't be needed. We have a lot of evidence that many programmers do not write such careful code, going back to Spaf's notes on the Robert T Morris finger worm in the late 1980's.
You also would prefer not to have to duplicate 10 lines of code for every call site of strcpy. That leads to unreadable code. More so, what zwol suggests is really just an implementation of the function he claims we don't need. A good programmer would take that, stick it in a header, and name it something helpful, maybe checked_strcpy? Or even strcpy_s?
The second suggested implementation, which is purportedly better is not - it would cause an allocation when we might already have a buffer. Allocations are expensive, using this approach everywhere would be bad for perf. It also introduces new complexity because now we'd have to free every duplicated string - imagine doing that with repeated calls to strcat.
There is a fairly nicely done cross-platform implementation here:
https://github.com/intel/safestringlib
I'm also not sure whether this is actually any different, but worth taking a look - https://github.com/coruus/safeclib
Using gcc and ld on x86_64 linux I need to link against a newer version of a library (glibc 2.14) but the executable needs to run on a system with an older version (2.5). Since the only incompatible symbol is memcpy (needing memcpy#GLIBC_2.2.5 but the library providing memcpy#GLIBC_2.14), I would like to tell the linker that instead of taking the default version for memcpy, it should take an old version I specify.
I found a quite arkward way to do it: simply specify a copy of the old .so file at the linker command line. This works fine, but I don't like the idea of having multiple .so files (I could only make it work by specifying all old libraries I link to that also have references to memcpy) checked into the svn and needed by my build system.
So I am searching for a way to tell the linker to take the old versioned symbol.
Alternatives that don't work (well) for me are:
Using asm .symver (as seen on Web Archive of Trevor Pounds' Blog) since this would require me to make sure the symver is before all the code that is using memcpy, which would be very hard (complex codebase with 3rd party code)
Maintaining a build environment with the old libraries; simply because I want to develop on my desktop system and it would be a pita to sync stuff around in our network.
When thinking about all the jobs a linker does, it doesn't seem like a hard thing to imlpement, after all it has some code to figure out the default version of a symbol too.
Any other ideas that are on the same complexity level as a simple linker command line (like creating a simple linker script etc.) are welcome too, as long as they are not weird hacks like editing the resulting binary...
edit:
To conserve this for the future readers, additionally to the below ideas I found the option --wrap to the linker, which might be useful sometimes too.
I found the following working solution. First create file memcpy.c:
#include <string.h>
/* some systems do not have newest memcpy##GLIBC_2.14 - stay with old good one */
asm (".symver memcpy, memcpy#GLIBC_2.2.5");
void *__wrap_memcpy(void *dest, const void *src, size_t n)
{
return memcpy(dest, src, n);
}
No additional CFLAGS needed to compile this file. Then link your program with -Wl,--wrap=memcpy.
Just link memcpy statically - pull memcpy.o out of libc.a ar x /path/to/libc.a memcpy.o (whatever version - memcpy is pretty much a standalone function) and include it in your final link. Note that static linking may complicate licensing issues if your project is distributed to the public and not open-source.
Alternatively, you could simply implement memcpy yourself, though the hand-tuned assembly version in glibc is likely to be more efficient
Note that memcpy#GLIBC_2.2.5 is mapped to memmove (old versions of memcpy consistently copied in a predictable direction, which led to it sometimes being misused when memmove should have been used), and this is the only reason for the version bump - you could simply replace memcpy with memmove in your code for this specific case.
Or you could go to static linking, or you could ensure that all systems on your network have the same or better version than your build machine.
I had a similar issue. A third party library we use needs the old memcpy#GLIBC_2.2.5. My solution is an extended approach #anight posted.
I also warp the memcpy command, but i had to use a slightly different approach, since the solution #anight posted did not work for me.
memcpy_wrap.c:
#include <stddef.h>
#include <string.h>
asm (".symver wrap_memcpy, memcpy#GLIBC_2.2.5");
void *wrap_memcpy(void *dest, const void *src, size_t n) {
return memcpy(dest, src, n);
}
memcpy_wrap.map:
GLIBC_2.2.5 {
memcpy;
};
Build the wrapper:
gcc -c memcpy_wrap.c -o memcpy_wrap.o
Now finally when linking the program add
-Wl,--version-script memcpy_wrap.map
memcpy_wrap.o
so that you will end up with something like:
g++ <some flags> -Wl,--version-script memcpy_wrap.map <some .o files> memcpy_wrap.o <some libs>
I had a similar problem. Trying to install some oracle components on RHEL 7.1, I got this:
$ gcc -o /some/oracle/bin/foo .... -L/some/oracle/lib ...
/some/oracle/lib/libfoo.so: undefined reference to `memcpy#GLIBC_2.14'
It seems that (my) RHEL's glibc only defines memcpy#GLIBC_2.2.5:
$ readelf -Ws /usr/lib/x86_64-redhat-linux6E/lib64/libc_real.so | fgrep memcpy#
367: 000000000001bfe0 16 FUNC GLOBAL DEFAULT 8 memcpy##GLIBC_2.2.5
1166: 0000000000019250 16 FUNC WEAK DEFAULT 8 wmemcpy##GLIBC_2.2.5
So, I managed to get around this, by first creating a memcpy.c file without wrapping, as follows:
#include <string.h>
asm (".symver old_memcpy, memcpy#GLIBC_2.2.5"); // hook old_memcpy as memcpy#2.2.5
void *old_memcpy(void *, const void *, size_t );
void *memcpy(void *dest, const void *src, size_t n) // then export memcpy
{
return old_memcpy(dest, src, n);
}
and a memcpy.map file that exports our memcpy as memcpy#GLIBC_2.14:
GLIBC_2.14 {
memcpy;
};
I then compiled my own memcpy.c into a shared lib like this:
$ gcc -shared -fPIC -c memcpy.c
$ gcc -shared -fPIC -Wl,--version-script memcpy.map -o libmemcpy-2.14.so memcpy.o -lc
, moved libmemcpy-2.14.so into /some/oracle/lib (pointed to by -L arguments in my linking), and linked again by
$ gcc -o /some/oracle/bin/foo .... -L/some/oracle/lib ... /some/oracle/lib/libmemcpy-2.14.so -lfoo ...
(which compiled without errors) and verified it by:
$ ldd /some/oracle/bin/foo
linux-vdso.so.1 => (0x00007fff9f3fe000)
/some/oracle/lib/libmemcpy-2.14.so (0x00007f963a63e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f963a428000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f963a20c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f963a003000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9639c42000)
/lib64/ld-linux-x86-64.so.2 (0x00007f963aa5b000)
This worked for me. I hope it does it for you, too.
I'm clearly a little late responding to this but I recently upgraded (more reasons to never upgrade) my Linux OS to XUbuntu 14.04 which came with the new libc. I compile a shared library on my machine which is used by clients who, for whatever legitimate reasons, have not upgraded their environment from 10.04. The shared library I compiled no longer loaded in their environment because gcc put a dependency on memcpy glibc v. 2.14 (or higher). Let's leave aside the insanity of this. The workaround across my whole project was three fold:
added to my gcc cflags: -include glibc_version_nightmare.h
created the glibc_version_nightmare.h
created a perl script to verify the symbols in the .so
glibc_version_nightmare.h:
#if defined(__GNUC__) && defined(__LP64__) /* only under 64 bit gcc */
#include <features.h> /* for glibc version */
#if defined(__GLIBC__) && (__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 14)
/* force mempcy to be from earlier compatible system */
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5");
#endif
#undef _FEATURES_H /* so gets reloaded if necessary */
#endif
perl script fragment:
...
open SYMS, "nm $flags $libname |";
my $status = 0;
sub complain {
my ($symbol, $verstr) = #_;
print STDERR "ERROR: $libname $symbol requires $verstr\n";
$status = 1;
}
while (<SYMS>) {
next unless /\#\#GLIBC/;
chomp;
my ($symbol, $verstr) = (m/^\s+.\s(.*)\#\#GLIBC_(.*)/);
die "unable to parse version from $libname in $_\n"
unless $verstr;
my #ver = split(/\./, $verstr);
complain $symbol, $verstr
if ($ver[0] > 2 || $ver[1] > 10);
}
close SYMS;
exit $status;
Minimal runnable self contained example
GitHub upstream.
main.c
#include <assert.h>
#include <stdlib.h>
#include "a.h"
#if defined(V1)
__asm__(".symver a,a#LIBA_1");
#elif defined(V2)
__asm__(".symver a,a#LIBA_2");
#endif
int main(void) {
#if defined(V1)
assert(a() == 1);
#else
assert(a() == 2);
#endif
return EXIT_SUCCESS;
}
a.c
#include "a.h"
__asm__(".symver a1,a#LIBA_1");
int a1(void) {
return 1;
}
/* ## means "default version". */
__asm__(".symver a2,a##LIBA_2");
int a2(void) {
return 2;
}
a.h
#ifndef A_H
#define A_H
int a(void);
#endif
a.map
LIBA_1{
global:
a;
local:
*;
};
LIBA_2{
global:
a;
local:
*;
};
Makefile
CC := gcc -pedantic-errors -std=c89 -Wall -Wextra
.PHONY: all clean run
all: main.out main1.out main2.out
run: all
LD_LIBRARY_PATH=. ./main.out
LD_LIBRARY_PATH=. ./main1.out
LD_LIBRARY_PATH=. ./main2.out
main.out: main.c libcirosantilli_a.so
$(CC) -L'.' main.c -o '$#' -lcirosantilli_a
main1.out: main.c libcirosantilli_a.so
$(CC) -DV1 -L'.' main.c -o '$#' -lcirosantilli_a
main2.out: main.c libcirosantilli_a.so
$(CC) -DV2 -L'.' main.c -o '$#' -lcirosantilli_a
a.o: a.c
$(CC) -fPIC -c '$<' -o '$#'
libcirosantilli_a.so: a.o
$(CC) -Wl,--version-script,a.map -L'.' -shared a.o -o '$#'
libcirosantilli_a.o: a.c
$(CC) -fPIC -c '$<' -o '$#'
clean:
rm -rf *.o *.a *.so *.out
Tested on Ubuntu 16.04.
This workaround seem not compatible with -flto compile option.
My solution is calling memmove. memove does exactly the same jobs than memcpy.
The only difference is when src and dest zone overlap, memmove is safe and memcpy is unpredictable. So we can safely always call memmove instead memcpy
#include <string.h>
#ifdef __cplusplus
extern "C" {
#endif
void *__wrap_memcpy(void *dest, const void *src, size_t n)
{
return memmove(dest, src, n);
}
#ifdef __cplusplus
}
#endif
For nim-lang, I elaborated on a solution I found using the C compiler --include= flag as follows:
Create a file symver.h with:
__asm__(".symver fcntl,fcntl#GLIBC_2.4");
Build your program with nim c ---passC:--include=symver.h
As for me I'm cross compiling too. I compile with nim c --cpu:arm --os:linux --passC:--include=symver.h ... and I can get symbol versions using arm-linux-gnueabihf-objdump -T ../arm-libc.so.6 | grep fcntl
I had to remove ~/.cache/nim at some point. And it seems to work.
I think you can get away with making a simple C file containing the symver statement and perhaps a dummy function calling memcpy. Then you just have to ensure that the resulting object file is the first file given to linker.
I suggest you either link memcpy() statically; or find the source of memcpy( ) and compile it as your own library.
It may caused by old ld (gnu link) version.
For following simple problem:
#include <string.h>
#include <stdio.h>
int main(int argc,char **argv)
{
char buf[5];
memset(buf,0,sizeof(buf));
printf("ok\n");
return 0;
}
When I use ld 2.19.1, memset is relocated to: memset##GLIBC_2.0, and cause crash.
After upgraded to 2.25, it is: memset#plt, and crash solved.
We had a similar issue, but instead of one older GLIBC symbol, we have to provide in our .so libs a mix of newer ones with necessary functionality and older ones our libs may be referencing but are not available. This situation occurs because we are shipping to customers high performance codec libs with vectorized math functions and we cannot impose requirements on what version of OS distro, gcc, or glibc they use. As long as their machine has appropriate SSE and AVX extensions, the libs should work. Here is what we did:
Include glibc 2.35 libmvec.so.1 and libm.so.6 files in a separate subfolder. These contain the necessary vectorized math functions. In a "hello codec" application example, we reference these in the link target depending on what distro, gcc, and glibc versions are found by the Makefile. More or less, for anything with glibc v2.35 or higher the high performance libs are referenced, otherwise slower libs are referenced.
To deal with missing symbols -- the subject of this thread -- we used a modification of Ortwin Anermeier's solution, in turn based on anight's solution, but without using the -Wl,--wrap=xxx option.
The .map file looks like:
GLIBC_2.35 {
hypot;
:
: (more function symbols as needed)
};
GLIBC_2.32 {
exp10;
:
: (more function symbols as needed)
};
:
: (more version nodes as needed)
and in a "stublib" .so we have:
#define _GNU_SOURCE
#include <math.h>
asm(".symver hypot_235, hypot#GLIBC_2.35");
asm(".symver exp10_232, exp10f#GLIBC_2.32");
/* ... more as needed */
double hypot_235(double x, double y) { return hypot(x, y); }
double exp10_232(double x) { return exp10(x); }
/* ... more as needed */
-lstublib.so is then included in the app build as the last link item, even after -lm.
This answer and this one also offer clues, but they not handling the general case of a .so flexible enough to be used on a wide variety of systems.