Перемещение R_X86_64_32S к `.rodata' ... При компиляции на 64-битной платформе
Так что я что-то кодировал на 32-битной и вчера мне нужно было собрать DLL, и у меня была пара проблем с этим. Во всяком случае, я решил их здесь.
К сожалению, даже если бы я думал, что все работает в конце концов, я обнаружил, что это не тот случай, когда я перенес свою программу и make-файл на другой компьютер, работающий на 64-битной системе, как вы можете догадаться, что произошло...
Так что моя проблема связана с перемещением из-за 64-битных
/usr/bin/ld: MyClass.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
MyClass.o: could not read symbols: Bad value
и вот мой make-файл
MyProgram: main.o chkopts
-${CLINKER} -o $@ $< ${MYLIB} ${PETSC_MAT_LIB}
${RM} main.o
export LD_LIBRARY_PATH=${LIBADD}:$LD_LIBRARY_PATH
LibMyProgram.so: MyClass.o chkopts
-${CLINKER} -shared -Wl,-soname,${SONAME} -o ${VERS} *.o ${PETSC_MAT_LIB}
mv ${VERS} ${LIBADD}
ln -sf ${LIBADD}${VERS} ${LIBADD}${SOWOV}
ln -sf ${LIBADD}${VERS} ${LIBADD}${SONAME}
Я пытался добавить -fPIC в CFLAGS, CPPFLAGS и даже LDFLAGS. Я также попытался добавить флаг -fPIC до и после -shared.
-${CLINKER} -shared -fPIC -Wl,-soname,${SONAME} -o ${VERS} *.o ${PETSC_MAT_LIB}
Но я получу ту же ошибку, что и раньше.
Если я использую CFLAGS = -fPIC, я получу немного такую же ошибку, которая:
.../petsc/petsc-3.2-p6/arch-linux2-cxx-debug/lib/libpetsc.a(err.o): relocation R_X86_64_32 against `ompi_mpi_comm_self' can not be used when making a shared object; recompile with -fPIC.
Я прочитал обо всех темах, которые даже отдаленно похожи на мою проблему, но я не смог понять это.
8 ответов
Решение было собрать все с -fPIC
и связать общие объекты с -shared
,
добавлять -fPIC
в CFLAGS
или же CXXFLAGS
для основанных на проекте проектов.
Я столкнулся с той же проблемой, когда пытался создать общую библиотеку, в которой нужно связать статическую библиотеку.
Я решил проблему, добавив -fPIC к CXXFLAGS для компиляции файлов.o, которые заархивированы в статической библиотеке.
Пытаясь скомпилировать xmlrpc-c-1.06.41 в CentOS 6.5, я столкнулся с той же проблемой компоновки, которая была решена следующим образом: в./src/cpp я изменил Makefile: строка 142 для
CXXFLAGS = $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD) -shared -fPIC
Более подробную информацию о флагах можно найти по ссылке
Если после добавления "-fPIC" эта проблема все еще существует, попробуйте очистить все файлы.o и снова запустите
Я тоже сталкиваюсь с этой проблемой. Как я пытаюсь использовать @Mare и @user2391685, он может хорошо работать:
С помощью -fPIC
когда пришло время .o
файл: например:
gcc -Wall -fPIC -c hello.c -I./ -I/usr/lib/jvm/java/include/ -I/usr/lib/jvm/java/include/linux/
Тогда вы можете построить .so
файл:
gcc -Wall -rdynamic -shared -o libhello.so hello.o Main.h -I/usr/lib/jvm/java/include/ -I/usr/lib/jvm/java/include/linux/
Эта работа как шарм. для тех, кто еще не знает, это просто использовать
открытый файл с именем Makefile.am или Makefile. Просто до вашей конфигурации.
посмотрите код на этом _a_CXXFLAGS = или просто CXXFLAGS =
добавить после этого файлы -shared -fPIC
этот пример
перед
crypto_libmubdi_crypto_a_CXXFLAGS = $(AM_CXXFLAGS) $(PIC_FLAGS) $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD)
после
crypto_libmubdi_crypto_a_CXXFLAGS = $(AM_CXXFLAGS) $(PIC_FLAGS) $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD) -shared -fPIC
эти ошибки приводят к тому, что мы не помещаем общие для файлов или нуждаемся в строках / тегах -fPIC.
Примечание: у меня есть опыт построения блокчейна. и по этой причине добавлен этот крипто /sph_sha2big.c
В командной строке:
cmake -DCMAKE_EXE_LINKER_FLAGS="-no-pie"
Или в CMakeList.txt:
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -no-pie")
Перемещение R_X86_64_PC32 против неопределенного символа обычно происходит, когда LDFLAGS установлены с усилением, а CFLAGS нет. Обычно это происходит, когда configure.ac переопределяет все системные флаги с помощью CFLAGS = "something", вам нужно изменить его на CFLAGS+ = "something".
https://github.com/rpmfusion/lxdream/blob/master/lxdream-0.9.1-implicit.patchhttps://bugzilla.redhat.com/show_bug.cgi?id=1304277#c3