неопределенная ссылка на `shm_open '- как я могу определить виновника? - PullRequest
Новая
       70

неопределенная ссылка на `shm_open '- как я могу определить виновника?

2 голосов
/ 16 июня 2020

Я пытаюсь построить простую программу на основе библиотеки, которая сама зависит от librt. Библиотека компилируется отлично, и там используется флаг -lrt. Программа также отлично работает на amd64 с использованием cmake, но на arm64 это не удается. Это не кросс-компиляция, а прямое построение на цели. Я использую обычную систему сборки cmake (cmake ..; make).

Точно такая же система сборки также может компилировать другую программу, которая использует ту же библиотеку, но не те же функции из нее.

Вот ошибка сборки: 

[100%] Linking C executable mrun-talker
/usr/lib/gcc/aarch64-linux-gnu/7/../../../../lib/libsec-common.so: undefined reference to `shm_open'
/usr/lib/gcc/aarch64-linux-gnu/7/../../../../lib/libsec-common.so: undefined reference to `shm_unlink'

А вот команда компоновщика: 

/usr/bin/cc CMakeFiles/sec-talker.dir/main.c.o -o sec-talker  -lsec-common -lsec-rosc -lsec-api -ltert -lgcov -lm -lrt -lpthread

Команда компоновщика действительно содержит флаг -lrt в конце команда и lrt.so доступны для цели.

Есть ли вероятность, что, хотя библиотека компилируется нормально, она не будет правильно компоноваться и вызовет эту ошибку позже, когда я попытаюсь ее использовать?

Полный cmake-файл: 

get_filename_component(ProjectId ${CMAKE_CURRENT_SOURCE_DIR} NAME)
string(REPLACE " " "_" ProjectId ${ProjectId})
project(${ProjectId})
set(ExecName ${ProjectId})

enable_language(C)

find_package(Threads)

add_executable(${ExecName} main.c)

target_link_libraries(
    ${ExecName}
    # sec libraries
    sec-common
    sec-rosc
    sec-api
    tert
    # system libraries
    gcov
    m
    Threads::Threads
    rt
)

link_directories("/usr/local/lib")

install(TARGETS ${ExecName})

/ edit

Я использовал ldd для проверки связывания libse c -common. Вот результат (работающей) версии amd64: 

# ldd /usr/lib/libsec-common.so
    linux-vdso.so.1 (0x00007fff7e922000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa350ef000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ffa356ec000)

И (неработающей) версии arm64. 

# ldd /usr/lib/libsec-common.so
    linux-vdso.so.1 (0x0000ffffb2dc6000)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffb2c26000)
    /lib/ld-linux-aarch64.so.1 (0x0000ffffb2d9b000)

Я не вижу здесь проблемы tbh .

1 Ответ

0 голосов
/ 19 июля 2020

Проблема заключалась в том, что сама зависимость неправильно связала свою зависимость.

...