Łączenie ze starszą wersją symbolu w a.so plik

Znalazłem następujące rozwiązanie robocze. Najpierw Utwórz plik 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);
}

Do skompilowania tego pliku nie są potrzebne żadne dodatkowe CFLAGS. Następnie połącz swój program z -WL,--wrap=memcpy.

Miałem podobny problem. Biblioteka stron trzecich, z której korzystamy, potrzebuje starej memcpy@GLIBC_2.2.5. Moim rozwiązaniem jest podejście rozszerzone @ anight posted.

Wypaczam też komendę memcpy, ale musiałem zastosować nieco inne podejście, ponieważ opublikowane rozwiązanie @anight nie zadziałało u mnie.

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.Mapa:

GLIBC_2.2.5 {
   memcpy;
};

Zbuduj wrapper:

gcc -c memcpy_wrap.c -o memcpy_wrap.o

Teraz w końcu przy linkowaniu programu dodaj

• -Wl,--version-script memcpy_wrap.map
• memcpy_wrap.o

Tak, że skończysz z czymś takim jak:

g++ <some flags> -Wl,--version-script memcpy_wrap.map <some .o files> memcpy_wrap.o <some libs>

Miałem podobny problem. Po zainstalowaniu niektórych komponentów oracle na RHEL 7.1, mam to:

$ gcc -o /some/oracle/bin/foo .... -L/some/oracle/lib ... 
/some/oracle/lib/libfoo.so: undefined reference to `memcpy@GLIBC_2.14'

Wygląda na to, że (mój) glibc RHELA definiuje tylko 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

Udało mi się to obejść, najpierw tworząc memcpy.plik c bez zawijania, jak następuje:

#include <string.h>
asm (".symver old_memcpy, memcpy@GLIBC_2.2.5");       // hook old_memcpy as [email protected]
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);
}

I memcpy.plik map, który eksportuje naszą memcpy jako memcpy@GLIBC_2.14:

GLIBC_2.14 {
   memcpy;
};

Potem skompilowałem własną memcpy.c do wspólnej lib jak to:

$ gcc -shared -fPIC -c memcpy.c
$ gcc -shared -fPIC -Wl,--version-script memcpy.map -o libmemcpy-2.14.so memcpy.o -lc

, przeniesiony libmemcpy-2.14.so do /some / oracle / lib (wskazywane przez-L argumenty w moim linkowaniu), i linkowane ponownie przez

$ gcc -o /some/oracle/bin/foo .... -L/some/oracle/lib ... /some/oracle/lib/libmemcpy-2.14.so -lfoo ...

(który skompilował bez błędów) i zweryfikował przez:

$ 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)

Jestem wyraźnie trochę spóźniony, ale niedawno uaktualniłem (więcej powodów, aby nigdy nie aktualizować) mój system operacyjny Linux do Xubuntu 14.04, który przyszedł z nowym libc. Kompiluję bibliotekę współdzieloną na moim komputerze, która jest używana przez klientów, którzy Z uzasadnionych powodów nie zaktualizowali swojego środowiska od wersji 10.04. Skompilowana biblioteka współdzielona nie jest już ładowana w ich środowisku, ponieważ gcc uzależnia się od glibc memcpy w wersji 2.14 (lub wyższej). Zapomnijmy o tym szaleństwie. Obejście całego mojego projektu było trzykrotne:

1. dodano do mojego gcc cflags: - include glibc_version_nightmare.h
2. utworzono glibc_version_nightmare.h
3. utworzono skrypt Perla, aby zweryfikować symbole w .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

Fragment skryptu Perla:

...
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;

To obejście nie wydaje się zgodne z opcją kompilacji-flto.

#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

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. Mapa

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

Testowane na Ubuntu 16.04.

Dla nim-lang, opracowałem rozwiązanie, które znalazłem przy użyciu flagi kompilatora C --include= następująco:

Utwórz plik .h z:

__asm__(".symver fcntl,fcntl@GLIBC_2.4");

Zbuduj swój program z nim c ---passC:--include=symver.h

Co do mnie to też się krzyżuję. Kompiluję z nim c --cpu:arm --os:linux --passC:--include=symver.h ... i mogę uzyskać wersje symboli używając arm-linux-gnueabihf-objdump -T ../arm-libc.so.6 | grep fcntl

Musiałem usunąć ~/.cache/nim w pewnym momencie. I wydaje się, że działa.

Myślę, że uda ci się stworzyć prosty plik C zawierający instrukcję symver i być może fałszywą funkcję wywołującą memcpy. Następnie musisz tylko upewnić się, że wynikowy plik obiektowy jest pierwszym plikiem podanym linkerowi.

Proponuję albo połączyć statycznie memcpy (), albo znaleźć źródło memcpy () i skompilować je jako własną bibliotekę.

Może być spowodowana starą wersją LD (gnu link). Dla następującego prostego problemu:

#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;
}

Kiedy używam ld 2.19.1, memset zostaje przeniesiony do: memset@@GLIBC_2.0 i spowodować crash. Po uaktualnieniu do 2.25 jest to: memset@plt i crash rozwiązany.