即使下載後也找不到avrdude的GLIBC_2.29

即使下載後也找不到avrdude的GLIBC_2.29

avrdude我在使用時遇到了一些困難閃光我的微控制器。

它取決於libm.so.6 GLIBC_2.29它找不到。它查看/usr/lib/libm.so.6該文件實際所在的位置,但它也駐留在/lib/lib.so.6.

所以當我跑步時

sudo pacman -S glibc 

安裝/更新庫https://www.archlinux.org/packages/core/x86_64/glibc/

我非常確定我只是將其安裝到/lib/.

但既然avrdude查了/usr/lib還是沒找到。我很難理解這兩個目錄的含義,因為它有點搞砸了事情,而不是對我的情況有幫助。

我怎樣才能正確地做到這一點?

編輯

我想做一些愚蠢的事情,所以我做了,cp /lib/libm.so.6 /usr/lib/libm.o.6cp命令告訴我文件是相同的。

現在我不明白為什麼avrdude找不到正確的 GLIBC 版本,因為它已正確更新(據我所知)。

答案1

請注意,安裝的檔案 是不glibc完整的。C runtime.C runtime--sysrootsysroot

同一個系統上很可能有多個版本的 glibc(我們每天都會這樣做)。

但是,您需要知道 glibc 由許多部分(200 多個共享庫)組成,所有部分都必須匹配。其中之一是 ld-linux.so.2,它必須與 libc.so.6 匹配,否則您將看到所看到的錯誤。

ld-linux.so.2 的絕對路徑在連結時會硬編碼到執行檔中,並且在連結完成後不能輕易更改。

若要建置可與新 glibc 一起使用的可執行文件,請執行下列操作:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

連結-rpath器選項將使運行時載入程式在其中搜尋庫/path/to/newglibc(因此您不必LD_LIBRARY_PATH在運行之前進行設定),並且該-dynamic-linker選項將「烘焙」路徑以更正ld-linux.so.2到應用程式中。

如果您無法重新連結myapp應用程式(例如,因為它是第三方二進位檔案),並非所有內容都會遺失,但會變得更加棘手。一種解決方案是chroot為其設定合適的環境。另一種可能性是使用RTDI和一個二進制編輯器。

解決方案#1

LD_PRELOAD='mylibc.so anotherlib.so' program

解決方案#2

無需專用 GCC 即可編譯自己的 glibc 並使用它

此設定可能有效且速度很快,因為它不會重新編譯整個 GCC 工具鏈,而只是 glibc。

但它並不可靠,因為它使用主機 C 運行時對象,例如crt1.o, crti.o、 和crtn.oglibc 提供的對象。這在以下位置提到:https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location這些物件會進行 glibc 所依賴的早期設置,因此如果事情以奇妙且極其微妙的方式崩潰,我不會感到驚訝。

要獲得更可靠的設置,請參閱下面的設置 2。

本地建置glibc並安裝:

export glibc_install="$(pwd)/glibc/build/install"

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`

設定 1:驗證構建

測試_glibc.c

#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

atomic_int acnt;
int cnt;

int f(void* thr_data) {
    for(int n = 0; n < 1000; ++n) {
        ++cnt;
        ++acnt;
    }
    return 0;
}

int main(int argc, char **argv) {
    /* Basic library version check. */
    printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());

    /* Exercise thrd_create from -pthread,
     * which is not present in glibc 2.27 in Ubuntu 18.04.
     * https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
    thrd_t thr[10];
    for(int n = 0; n < 10; ++n)
        thrd_create(&thr[n], f, NULL);
    for(int n = 0; n < 10; ++n)
        thrd_join(thr[n], NULL);
    printf("The atomic counter is %u\n", acnt);
    printf("The non-atomic counter is %u\n", cnt);
}

編譯並運行test_glibc.sh

#!/usr/bin/env bash
set -eux
gcc \
  -L "${glibc_install}/lib" \
  -I "${glibc_install}/include" \
  -Wl,--rpath="${glibc_install}/lib" \
  -Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
  -std=c11 \
  -o test_glibc.out \
  -v \
  test_glibc.c \
  -pthread \
;
ldd ./test_glibc.out
./test_glibc.out

此程式輸出預期的結果:

gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674

命令改編自https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location但 --sysroot 使其失敗:

cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install

所以我把它刪除了。

ldd 輸出確認我們剛剛建立的 ldd 和函式庫實際上正在按預期使用:

+ ldd test_glibc.out
        linux-vdso.so.1 (0x00007ffe4bfd3000)
        libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
        libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
        /home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)

gcc 編譯偵錯輸出顯示使用了我的主機運行時對象,這很糟糕,如前面提到的,但我不知道如何解決它,例如它包含:

COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o

設定1:修改glibc

現在讓我們修改 glibc:

diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
@@ -16,11 +16,14 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */

+#include <stdio.h>
+
 #include "thrd_priv.h"

 int
 thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
 {
+  puts("hacked");
   _Static_assert (sizeof (thr) == sizeof (pthread_t),
                   "sizeof (thr) != sizeof (pthread_t)");

然後重新編譯並重新安裝glibc,並重新編譯並重新執行我們的程式:

cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh

我們看到 hacked 按預期打印了幾次。

這進一步證實了我們實際上使用了我們編譯的 glibc 而不是主機。

在 Ubuntu 18.04 上測試。

資料來源:

https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host/851229#851229

https://sourceware.org/glibc/wiki/Testing/Builds?action=recallrev=21#Compile_against_glibc_in_an_installed_location

相關內容