Вот вывод ошибки make test в директории src
make test в каталоге src, когда у проекта есть система сборки основанная на CMake и можно запускать make test в каталоге где выполняется сборка?make test в каталоге сборки тоже завершается успешно: 100% tests passed, 0 tests failed out of 132cd /home/jcmvbkbc/tmp/tests/1390844/kaldi/build/src/matrix && /usr/bin/c++ -DHAVE_CLAPACK=1 -DKALDI_NO_PORTAUDIO=1 -Dkaldi_matrix_EXPORTS -I/home/jcmvbkbc/tmp/tests/1390844/kaldi/build/_deps/openfst-src/src/include -I/home/jcmvbkbc/tmp/tests/1390844/kaldi/tools/CLAPACK -I/home/jcmvbkbc/tmp/tests/1390844/kaldi/src/matrix/.. -I/home/jcmvbkbc/tmp/tests/1390844/kaldi/src/base/.. -fPIC -std=c++14 -MD -MT src/matrix/CMakeFiles/kaldi-matrix.dir/kaldi-matrix.cc.o -MF CMakeFiles/kaldi-matrix.dir/kaldi-matrix.cc.o.d -o CMakeFiles/kaldi-matrix.dir/kaldi-matrix.cc.o -c /home/jcmvbkbc/tmp/tests/1390844/kaldi/src/matrix/kaldi-matrix.cc ./configure CC=arm-linux-gnueabi-gcc-7 --host=aarch64-linux-android //тут ОК
make // gcc: command not found
Мне надо ссылку делать в bin на arm-linux-gnueabi-gcc-7, или это костыль в данном случае
Что означает ошибка «Error: relocation ... cannot be used with -shared»
gcc -fpic). Из-за того что динамические библиотеки могут быть загружены в процесс по любому адресу существует требование, что код в них должен быть position-independent. Поэтому объектники скомпилированные как position-dependent обычно не могут быть слинкованы в динамическую библиотеку. R_AARCH64_TLSLE_ADD_TPREL_HI12 говорит (частью TLSLE, где LE означает Local Executable) о том, что код объектника в котором она находится был намеренно собран с рассчётом на то, что объектник будет частью исполняемого файла, а не динамической библиотеки. Здесь можно почитать об отличиях моделей адресации TLS, в частности о модели Local Exec в разделе 4.4. пишет, что не может найти "efi.h", хотя он есть в папке inc из Makefile
inc определённую в 7й строке, то ты её нигде не использовал, а сами по себе переменные с произвольными именами в Makefile ничего не значат.gcc -fshort-wchar -I -I/ -I/usr/include -O2 -Wall -fpic -DEFI_FUNCTION_WRAPPER -ffreestanding -nostdlib -c main.c -o main.o main.c:1:10: фатальная ошибка: efi.h: Нет такого файла или каталога
-I ты не указал своего каталога inc, как по-твоему компилятор должен понять, что efi.h нужно там искать?-I$(EFIINC)EFIINC, откуда ты ожидаешь что она возьмётся?inc на EFIINC, lib на EFILIB, crtobj на CRTOBJ и т. д. Как это решается в других проектах?
создал мэйк файл с помощью утилиты autotools. все получилось кроме настройки make install.
дополнительные папки с конфигами и картинками.
install-data-local. После сборки чужой библиотеки из исходного кода, появился файл с расширением .lib
Что делать с ним - непонятно,
windres lib/glut/glut.rc lib/glut/resources.o : Invalid argumentresources.o
в чем может быть дело
windres lib\glut\glut.rc lib\glut\resources.oПодскажите пожалуйста, почему так
a b c символы, которые нужны библиотеке b будут искаться только в библиотеке c, но не в a. Если между библиотеками нет циклических зависимостей (т.е. нет такого, что a определяет символ, нужный b, а b определяет символ, нужный a), то их можно упорядочить так, что линковка будет успешной (см. топологическая сортировка). Если циклические зависимости есть, или сортировать лень, можно перечислить нужные библиотеки несколько раз или взять их в группу:g++ main.cpp -Wl,--start-group -lglfw3 -lgdi32 -lopengl32 -lglew32s -Wl,--end-group пишу ключ -static
'-static'
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
линковать с ключем -dynamic.
Проект создаёт статическую библиотеку mylib, но в неё не включена требуемая реализация boost, то есть при линковке приложения с mylib нужно явно указывать, что нужно линковать boost.
pkg-config --libs <имя библиотеки>и получает список ключей для линковки. build/obj/%.obj: %.cpp $(USER_CFG_H_FILE) $(FREE_RTOS_H_FILE)FREE_RTOS_H_FILE := FreeRTOS_for_stm32f2/include/FreeRTOS.hFREE_RTOS_H_FILE := FreeRTOS_for_stm32f2/FreeRTOS.h