LINUX.ORG.RU

6
Всего сообщений: 86

No such file or directory

$ ls -l icecat
-rwxr-xr-x 1 user users 199800 May 29 2019 icecat
$ ./icecat
bash: ./icecat: No such file or directory

Это про что?

 , ,

jhonathan ()

Cлинковать обьектный файл в котором уже есть main в свою программу

Допустим, есть файлы tool.cpp, tool.h и my_tool.cpp

Где в tool.h объявлены какие-то вспомогательные функции, которые реализованы в tool.cpp. Кроме того, в tool.cpp есть main.

В my_tool.cpp мне хочется использовать все эти замечательные функции из tool.h, однако имеющийся там main мешается.

Решения здорового человека в «духе перетащить все функции в хедер», вынести main из tool.cpp понятны и разумны, но можно ли как-то сказать линкеру чтобы вместо

multiple definition of `main'; my_tool.cpp:19: first defined here

Он просто взял конкретный main, а второй выкинул?

P.S. Если собирать через afl-cc, то проблемы с линкером нет, левый main не участвует. Я посмотрел какие флаги он добавляет, но там ничего похоже нет, просто свои символы еще.

 , ,

chuemir ()

libstdc++.so.6: version `GLIBCXX_3.4.20' not found

Собираем код под убунтой 16.04, добавилась зависимость от плюсом.

Пытаются запустить под Centos 7, там не находятся нужные символы.

Вопрос: а если при компиляции/линковке вообще убрать зависимости от версии GLIBC, т.е. пусть будь что будет и при старте свяжется с той версией функции, которая есть в библиотеке, то что может плохого произойти?

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

 ,

max_lapshin ()

запуск программы в chroot

Как запустить программу в chroot, из которого недоступен исполняемый файл програмы(а также зависимые динамические библиотеки)?

Может можно динамическому линкеру сказать что бы он только слинковал программу и не запускал её? Потом выполнить чрут и передать исполнение слинкованной программе, которая уже в памяти лежит.

 , ,

urquan ()

undefined reference to

Что-то не пойму, в чём дело. Есть докер-контейнер, в котором развёрнута Убунту и сборочное окружение. При сборке исходники компилируются, но отказываются линковаться с libportaudio, выдавая серию сообщений вроде «undefined reference to `Pa_Initialize'». dev-файлы для portaudio установлены:

# ls /usr/lib/x86_64-linux-gnu/ | grep -i portaudio
libportaudio.a
libportaudio.so
libportaudio.so.2
libportaudio.so.2.0.0
libportaudiocpp.a
libportaudiocpp.so
libportaudiocpp.so.0
libportaudiocpp.so.0.0.12
Линкер упорно игнорирует и -lportaudio, и -L/usr/lib/x86_64-linux-gnu/. Под Федорой всё компилируется, правда, не в контейнере.

Где я не прав?

 , , , ,

meliafaro ()

sublime text 2 , c++ и undefined reference to <function>

Добрый вечер. В sublime text 2 запускаю следующий c++ код :


#include <GL/freeglut.h>
#include <GL/gl.h>

void Keyboard( unsigned char Key, int X, int Y ) {
	if (Key == 27)
		exit(0);
}

int main( int argc, char *argv[] ) {
	glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);

    glutInitWindowPosition(230, 230);
    glutInitWindowSize(600, 600);
    glutCreateWindow("my_window");

    glutKeyboardFunc(Keyboard);

    glutMainLoop();

    return 0;
}

На что получаю :


/usr/bin/ld: /tmp/ccYxHTd1.o: in function `main':
main.cpp:(.text+0x44): undefined reference to `glutInit'
/usr/bin/ld: main.cpp:(.text+0x4e): undefined reference to `glutInitDisplayMode'
/usr/bin/ld: main.cpp:(.text+0x5d): undefined reference to `glutInitWindowPosition'
/usr/bin/ld: main.cpp:(.text+0x6c): undefined reference to `glutInitWindowSize'
/usr/bin/ld: main.cpp:(.text+0x78): undefined reference to `glutCreateWindow'
/usr/bin/ld: main.cpp:(.text+0x84): undefined reference to `glutKeyboardFunc'
/usr/bin/ld: main.cpp:(.text+0x89): undefined reference to `glutMainLoop'
collect2: error: ld returned 1 exit status
[Finished in 0.2s with exit code 1]

Как с этим быть? Спасибо ^^

 , , ,

ihni ()

Вопросик по ld

Собрал вот такую либу rtcConn.node

g++ -shared -pthread -rdynamic -m64 -z noexecstack -z relro -Wl,-soname=rtcConn.node -o Debug/obj.target/rtcConn.node -Wl,--start-group Debug/obj.target/rtcConn/addon.o Debug/obj.target/rtcConn/WebRtcConnection.o Debug/obj.target/rtcConn/ThreadPool.o Debug/obj.target/rtcConn/IOThreadPool.o Debug/obj.target/rtcConn/MediaStream.o Debug/obj.target/rtcConn/conn_handler/WoogeenHandler.o Debug/obj.target/rtcConn/erizo/src/erizo/DtlsTransport.o Debug/obj.target/rtcConn/erizo/src/erizo/IceConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/LibNiceConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/SdpInfo.o Debug/obj.target/rtcConn/erizo/src/erizo/SrtpChannel.o Debug/obj.target/rtcConn/erizo/src/erizo/Stats.o Debug/obj.target/rtcConn/erizo/src/erizo/StringUtil.o Debug/obj.target/rtcConn/erizo/src/erizo/WebRtcConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/MediaStream.o Debug/obj.target/rtcConn/erizo/src/erizo/lib/LibNiceInterfaceImpl.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/IOThreadPool.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/IOWorker.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/Scheduler.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/ThreadPool.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/Worker.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/PacketBufferService.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtcpForwarder.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtcpProcessorHandler.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtpUtils.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/QualityManager.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtpExtensionProcessor.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/DtlsSocket.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/DtlsClient.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/bf_dwrap.o Debug/obj.target/rtcConn/erizo/src/erizo/pipeline/Pipeline.o Debug/obj.target/rtcConn/erizo/src/erizo/stats/StatNode.o -Wl,--end-group -L/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib -lsrtp2 -lssl -ldl -lcrypto -llog4cxx -lboost_thread -lboost_system -lnice


Эти строчки указывают на то, что подключаемые библиотеки лежат в папке ...build/lib и нужно прилинковать либу ssl
-L/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib
-lssl


Я потом смотрю
ldd rtcConn.node
        linux-vdso.so.1 (0x00007fff90ff4000)
        libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4cbdf50000)
        libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f4cbda85000)
        liblog4cxx.so.10 => /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10 (0x00007f4cbd6bc000)
        libboost_thread.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1 (0x00007f4cbd497000)
        libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f4cbd292000)
        libnice.so.10 => not found
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4cbcf09000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4cbcb6b000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4cbc953000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4cbc734000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4cbc343000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4cbe549000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4cbc13f000)
        libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f4cbbf0a000)
        libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007f4cbbcdf000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4cbbad7000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f4cbb8d0000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4cbb698000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f4cbb466000)


и вижу что libssl берется вообще из /usr/lib/, хотя должно быть из ...build/lib. Почему так?

 , ,

gobot ()

Link-Time Cyclic Dependencies: как их все найти?

Есть большой проект в котором есть циклические зависимости при линковании. Каким набором инструментов можно выявить все циклы, чтобы их потом ликвидировать?

 ,

invy ()

Как это объяснить?

g++ -lGL -lGLEW -lglfw -lpthread temp.cpp

/tmp/ccoXvv4n.o: In function `main':
temp.cpp:(.text+0x10): undefined reference to `glfwInit'
temp.cpp:(.text+0x1f): undefined reference to `glfwWindowHint'
temp.cpp:(.text+0x2e): undefined reference to `glfwWindowHint'
temp.cpp:(.text+0x3d): undefined reference to `glfwWindowHint'
temp.cpp:(.text+0x5e): undefined reference to `glfwCreateWindow'
temp.cpp:(.text+0x94): undefined reference to `glfwMakeContextCurrent'
temp.cpp:(.text+0x9a): undefined reference to `glewExperimental'

ldconfig -p | grep -i "glew\|glfw\|gl.so"

        libglfw.so.3 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libglfw.so.3
        libglfw.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libglfw.so
        libOpenGL.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0
        libOpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libOpenGL.so
        libGLEW.so.2.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0
        libGLEW.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGLEW.so
        libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
        libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so

ld --verbose | grep -o "SEARCH_DIR(\"=/usr/lib/x86_64-linux-gnu\")"

SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")

objdump -T /usr/lib/x86_64-linux-gnu/libglfw.so | grep glfwInit

0000000000005b10 g    DF .text  000000000000007f  Base        glfwInit

Если поменять g++ на clang++-8, то всё компилируется

kde neon

 ,

yachmenka ()

Можно ли собрать бинарик с кастомным /lib/ld.so.1 по-умолчанию в качестве интерпритатора бинарика?

Смеркалось.

Собрал valgrind под мипсельную железяку. При запуске на железяке простит libc6-dbg. ld.so.1 и libc6.so.6 есть не стрипнутые, если запустить все в чруте, работает. А вот как запустить валгринд в основной системе(где либы стрипнутые), либо собрать валгринд так чтоб он по умолчанию искал ld.so.1 не в /lib/, а в /tmp/valgrind/lib ?

 , ,

pihter ()

Линкер валится при попытке собрать статическую библиотеку.

Собственно, сабж:

/usr/bin/ld.gold: internal error in open, at ../../gold/descriptors.cc:98
collect2: error: ld returned 1 exit status

Начал вылазить, когда я начитался советов по оптимизации, и попробовал собрать весь проект со статической линковкой. Собрать-то собрал, но он начал падать, причем отладчик стек не показывает(!?!?) (собирал с дебагинфо)

Решил добавить санитайзеров, и получил сабж. Подозреваю, дело в объеме, размер объектников либы 6 Гб, весь проект - 11 Гб

Куда копать-то?

 , ,

eagleivg ()

LTO не работает

Когда компилирую программу с -flto, в конце, во время линкования ошибка:

lto1: internal error: in add_symbol_to_partition_1, at lto/lto-partition.c:153
Пытаюсь поменять на gold, но и тут засада, пишет во время конфигурации meson:
-----
Sanity check compile stderr:
/usr/bin/ld.gold: error: cannot find -lugin
/usr/bin/ld.gold: error: cannot find -lugin-opt=/usr/lib/gcc/i686-linux-gnu/9/lto-wrapper
/usr/bin/ld.gold: error: cannot find -lugin-opt=-fresolution=/tmp/ccZU7VQK.res
/usr/bin/ld.gold: error: cannot find -lugin-opt=-pass-through=-lgcc
/usr/bin/ld.gold: error: cannot find -lugin-opt=-pass-through=-lgcc_s
/usr/bin/ld.gold: error: cannot find -lugin-opt=-pass-through=-lc
/usr/bin/ld.gold: error: cannot find -lugin-opt=-pass-through=-lgcc
/usr/bin/ld.gold: error: cannot find -lugin-opt=-pass-through=-lgcc_s
collect2: error: ld returned 1 exit status

-----

Compiler cc can not compile programs.

Кто меня проклял? Как включить эту парашу под названием LTO?

Meson: 0.52.0

Gcc: 9

Ld (и gold и bfd): 2.30

 , , , ,

gradle ()

Как обновить binutils на Ubuntu 14.04?

У меня установлена старая версия 2.24, на столько, что при линковке сыпятся тоннами ошибки, о которых я ломаю голову неделю уже. Но нигде в интернете нет инфы по обновлению для устаревших дистрибутивов. Не подскажите как?

Хотя бы версию 2.30, но мне нужна 2.33. Странно, что при установке gcc 9 он не ругался на это.

 , , ,

gradle ()

Mesa не компилируется со статическим LLVM через meson

Я пытаюсь скомпилировать mesa 19.2.1, в meson-options.txt отключил shared llvm, ввёл команды:

meson build/

ninja -C build/

Но мне выдаёт ошибку:

[1019/1047] Compiling C object 'src/ga...a9e9c@@llvmpipe@sta/lp_setup_tri.c.o'.
../src/gallium/drivers/llvmpipe/lp_setup_tri.c: In function ‘do_triangle_ccw’:
../src/gallium/drivers/llvmpipe/lp_setup_tri.c:706:33: warning: ‘scissor’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  706 |          plane_s->c = (1-scissor->y0) << 8;
      |                          ~~~~~~~^~~~
[1047/1047] Linking target src/gallium/targets/libgl-xlib/libGL.so.1.5.0.
FAILED: src/gallium/targets/libgl-xlib/libGL.so.1.5.0 
c++  -o src/gallium/targets/libgl-xlib/libGL.so.1.5.0 'src/gallium/targets/libgl-xlib/a6bea21@@GL@sha/xlib.c.o' -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libGL.so.1 src/gallium/state_trackers/glx/xlib/libxlib.a src/gallium/winsys/sw/xlib/libws_xlib.a src/mapi/glapi/libglapi_static.a src/gallium/auxiliary/libgallium.a src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a src/util/libmesa_util.a src/compiler/nir/libnir.a src/compiler/libcompiler.a src/mesa/libmesa_gallium.a src/mesa/libmesa_sse41.a src/gallium/drivers/llvmpipe/libllvmpipe.a src/gallium/drivers/softpipe/libsoftpipe.a src/gallium/drivers/swr/libmesaswr.a -Wl,-Bsymbolic -Wl,--gc-sections -Wl,--version-script /home/xdroid/Desktop/mesa/src/gallium/targets/libgl-xlib/libgl-xlib.sym -pthread /usr/lib/i386-linux-gnu/libX11.so /usr/lib/i386-linux-gnu/libXext.so /usr/lib/i386-linux-gnu/libxcb.so -lrt -ldl -lpthread -lm -L/usr/lib/llvm-8/lib -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMCore -lLLVMMCDisassembler -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -lz -ltinfo /usr/lib/i386-linux-gnu/libz.so -L/usr/lib/llvm-8/lib -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMCore -lLLVMMCDisassembler -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -lz -ltinfo -L/usr/lib/llvm-8/lib -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMCore -lLLVMMCDisassembler -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -lz -ltinfo -Wl,--end-group '-Wl,-rpath,$ORIGIN/../../state_trackers/glx/xlib:$ORIGIN/../../winsys/sw/xlib:$ORIGIN/../../../mapi/glapi:$ORIGIN/../../auxiliary:$ORIGIN/../../../compiler/glsl:$ORIGIN/../../../compiler/glsl/glcpp:$ORIGIN/../../../util:$ORIGIN/../../../compiler/nir:$ORIGIN/../../../compiler:$ORIGIN/../../../mesa:$ORIGIN/../../drivers/llvmpipe:$ORIGIN/../../drivers/softpipe:$ORIGIN/../../drivers/swr' -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/state_trackers/glx/xlib -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/winsys/sw/xlib -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/mapi/glapi -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/auxiliary -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/compiler/glsl -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/compiler/glsl/glcpp -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/util -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/compiler/nir -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/compiler -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/mesa -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/drivers/llvmpipe -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/drivers/softpipe -Wl,-rpath-link,/home/xdroid/Desktop/mesa/build/src/gallium/drivers/swr
/usr/lib/llvm-8/lib/libLLVMSupport.a(DynamicLibrary.cpp.o): In function `llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::string*)':
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary19getPermanentLibraryEPKcPSs+0x50): undefined reference to `dlopen'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary19getPermanentLibraryEPKcPSs+0xc1): undefined reference to `dlerror'
/usr/lib/llvm-8/lib/libLLVMSupport.a(DynamicLibrary.cpp.o): In function `llvm::sys::DynamicLibrary::HandleSet::AddLibrary(void*, bool, bool)':
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet10AddLibraryEPvbb[_ZN4llvm3sys14DynamicLibrary9HandleSet10AddLibraryEPvbb]+0xb1): undefined reference to `dlclose'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet10AddLibraryEPvbb[_ZN4llvm3sys14DynamicLibrary9HandleSet10AddLibraryEPvbb]+0x19a): undefined reference to `dlclose'
/usr/lib/llvm-8/lib/libLLVMSupport.a(DynamicLibrary.cpp.o): In function `llvm::sys::DynamicLibrary::HandleSet::Lookup(char const*, llvm::sys::DynamicLibrary::SearchOrdering)':
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE[_ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE]+0x4f): undefined reference to `dlsym'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE[_ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE]+0x78): undefined reference to `dlsym'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE[_ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE]+0xa9): undefined reference to `dlsym'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE[_ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE]+0xdf): undefined reference to `dlsym'
DynamicLibrary.cpp:(.text._ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE[_ZN4llvm3sys14DynamicLibrary9HandleSet6LookupEPKcNS1_14SearchOrderingE]+0x122): undefined reference to `dlsym'
/usr/lib/llvm-8/lib/libLLVMSupport.a(DynamicLibrary.cpp.o): In function `llvm::object_deleter<llvm::sys::DynamicLibrary::HandleSet>::call(void*)':
DynamicLibrary.cpp:(.text._ZN4llvm14object_deleterINS_3sys14DynamicLibrary9HandleSetEE4callEPv[_ZN4llvm14object_deleterINS_3sys14DynamicLibrary9HandleSetEE4callEPv]+0x3a): undefined reference to `dlclose'
DynamicLibrary.cpp:(.text._ZN4llvm14object_deleterINS_3sys14DynamicLibrary9HandleSetEE4callEPv[_ZN4llvm14object_deleterINS_3sys14DynamicLibrary9HandleSetEE4callEPv]+0x4d): undefined reference to `dlclose'
src/gallium/auxiliary/libgallium.a(util_u_dl.c.o): In function `util_dl_open':
/home/xdroid/Desktop/mesa/build/../src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen'
src/gallium/auxiliary/libgallium.a(util_u_dl.c.o): In function `util_dl_get_proc_address':
/home/xdroid/Desktop/mesa/build/../src/gallium/auxiliary/util/u_dl.c:62: undefined reference to `dlsym'
src/gallium/auxiliary/libgallium.a(util_u_dl.c.o): In function `util_dl_close':
/home/xdroid/Desktop/mesa/build/../src/gallium/auxiliary/util/u_dl.c:75: undefined reference to `dlclose'
src/gallium/auxiliary/libgallium.a(util_u_dl.c.o): In function `util_dl_error':
/home/xdroid/Desktop/mesa/build/../src/gallium/auxiliary/util/u_dl.c:88: undefined reference to `dlerror'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
xdroid@ubuntu:~/Desktop/mesa$ 

Попробовал по другому:

meson build/ -Dc_args=-ldl -Dcpp_args=-ldl -Dc_link_args=-ldl -Dcpp_link_args=-ldl -Dlink_args=-ldl -Dld_args=-ldl

ninja -C build/

Тоже самое. Что делать?

 , , , ,

gradle ()

Зачем нужен явный вызов ld?

Поделитесь секретом, зачем это нужно? Когда как можно просто запускать gcc со всеми объектными файлами.

 , ,

Northsoft ()

Вопрос про Ассемблер в Линуксе...

Добрый день !

Решил освоить ассемблер в линуксе ( nasm, Debian, компоновщик ld )

В коде программы можно вписать на языке nasm «bits16» и «bits32» - т.е. с разрядностью все понятно...

В консоли можно передать параметры nasm - f * ( где * - elf, bin, WIN32)...

Теперь сам вопрос:

Могу ли я находясь в Линуксе и пользуясь nasm + ld, написать и слинковать ИСПОЛНИМЫЙ КОД для windows 32 ??

P.s. Соответственно без wine и эмуляторов... просто слинковать по имеющимся данным....

 , , ,

crosscat ()

Бинарник был открыт, но «No such file or dirrectory”

Пытаюсь использовать функцию из libxxx.so, взятой из Windriver arm hf 2.6.32. Эмулирую на qemu Debian wheezy hf 3.2.0. Скомпилив простейший бинарник hello, где вызываю dlopen на libxxx.so, получаю ошибку «cannot open shared object file: No such file or dirrectory”. Хотя:

strace:

open("/usr/src/hello/libxxx.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330\26\0\0004\0\0\0"..., 512) = 512
lseek(3, 53056, SEEK_SET) = 53056
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400
lseek(3, 37784, SEEK_SET) = 37784
read(3, "A0\0\0\0aeabi\0\1&\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 49) = 49
close(3) = 0
writev(2, [{"./hello", 7}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libxxx.so", 13}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10./hello: error while loading shared libraries: libxxx.so: cannot open shared object file: No such file or directory
) = 120
exit_group(127)

# file libxxx.so:
ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
# uname -a:
Linux debian-armhf 3.2.0-4-vexpress #1 SMP Debian 3.2.51-1 armv7l GNU/Linux
# file hello:
ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26
# ldd hello : libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ee9000) libxxx.so => not found libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76e01000) /lib/ld-linux-armhf.so.3 
# ldconfig -p | grep libxxx.so : libxxx.so (libc6) => /lib/libxxx.so (it's not a link)
# ldd libxxx.so : not a dynamic executable

readelf говорит, что для libxxx.so NEEDED только libc. Секцию ARM.attributes смотрел, сверял с родными либами...

 , , , ,

botcser ()

Как линковать приложение на Vala с сишными либами?

Допустим, есть helloworld на Вале, который использует стороннюю библиотеку, предположим, libportmidi. Для portmidi уже есть соответствующий vapi-файл, который я положил к исходникам и указал на соответствующую директорию компилятору:

valac --vapidir=. --pkg portmidi pm_test.vala
В итоге всё это безобразие кое-как компилируется, но вылетает на линковке, поясняя это возгласом:
/tmp/ccQMlfPs.o: In function `_vala_main':
pm_test.vala.c:(.text+0x72): undefined reference to `Pm_GetDeviceInfo'
collect2: error: ld returned 1 exit status
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)

Как поступают белые люди в таких случаях?

 , , ,

meliafaro ()

collect2: cannot find 'ld'

Could somebody have met this problem, I have collect2: cannot find 'ld' error when try:

 gcc -pthread -I /tmp/usr/include -no-use-gold-linker /tmp/teeest.c -o /tmp/teeest > /tmp/ok.log 2>/tmp/error.log 

Result:

 collect2: cannot find 'ld'

Check ld existing:

ld: /usr/bin/ld /usr/share/man/man1/ld.1.gz

Check $PATH

/usr/local/bin:/bin:/usr/bin

I try to compile hello world application on C in /tmp dir. CentOS 6, 2016, 2.6.32-642.1.1.el6.x86_64, x86_64

 , , , ,

jenpayout ()

Добавить префикс для поиска интерпретатора

Привет. В исполняемых файлах зашита инофмация с абсолютными путями к загрузчику/интерпретатору (/lib64/ld-linux-x86-64.so, #!/bin/bash). Можно ли задать какой-то префикс, который будет прилепляться к абсолютному путю во время поиска? Например в консоле (псевдокоманда): # setprefix /sandbox; ./bash_script, и скрипт затребует /sandbox/bin/bash. Сомневаюсь, но вдруг есть какие-то варианты. Править исполняемые файлы - не вариант.

 ,

pavlick ()