Сборка dl в gcc x64

erotic

Такой вопросец: есть пакет artoolkit, который создает несколько статических библиотек, собираемых без -fPIC. Есть пакет osgART, который создает библиотеку osgart_artoolkit.so из нескольких исходных файлов, собираемых с -fPIC, и с такой командой сборки в Makefile:
osgart_artoolkit.so: $(OSGART_ARTOOLKIT_OBJECTS) libosgART.so
$(CXX) -shared -fPIC -o $@ $(OSGART_ARTOOLKIT_OBJECTS) $(LDFLAGS) -L$(ARTOOLKIT_PATH)/lib/ libosgART.so -lARvideo -losg -ldc1394_control
Здесь все линкуемые библиотеки, кроме ARvideo - динамические, а ARvideo - статическая из пакета artoolkit.
Все собирается под x32, но при сборке под x32_64 получаю ошибку:
g++ -shared -fPIC -o osgart_artoolkit.so osgart_artoolkit_ARToolKitVideo.o osgart_artoolkit_Main.o -L/usr/lib/ libosgART.so -lARvideo -losg -ldc1394_control
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib//libARvideo.a(video.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib//libARvideo.a: could not read symbols: Bad value
collect2: выполнение ld завершилось с кодом возврата 1
Приходится пересобирать artoolkit с -fPIC. Почему?

ppplva

Потому что на x32_64 text relocations не поддерживаются, и весь код в динамических библиотеках должен быть PI.

slonishka

я, кстати, в cmake по подобному поводу разочаровался:

This is a tricky problem. The linker will prefer shared over static
if there are two libraries. CMake splits the full path into
-L and -l because on some OS's a full path to a library on the link
line has some unexpected side effects ( putting the full path to
a shared library into the executable, linking all the .o files from
the .a)
So, the only way to get around this is to copy the postgres static library
into a different directory and link with that one.
-Bill

смешно, по-моему. столько костылей наворотили, а способа сделать такую простую штуку — нет.
http://www.cmake.org/pipermail/cmake/2004-April/004975.html

vall

а ты вот попробуй собери какую-нить нетривиальную прогу кросскомпиллятором (а сначала сам кросскомпиллятор) — разочаруешься в гцц и вообще во всём юнихе.
вся иерархия костылей давно эволюционировала в грабли =)

slonishka

а ты вот попробуй собери какую-нить нетривиальную прогу кросскомпиллятором (а сначала сам кросскомпиллятор) — разочаруешься в гцц и вообще во всём юнихе.вся иерархия костылей давно эволюционировала в грабли =)

да понятно. я же говорю о куда более тривиальной задаче.
у gcc для нее есть хотя бы костыль. у cmake этого сделать невозможно в принципе.

conv3rsje

Если ядро - нетривиальная прога, то все нормально компилируется
По крайней мере под дебом создание песочницы было довольно простым

vall

ядро особенное в хорошем смысле, гсс — в плохом.