GnuCOBOL не удается найти динамические символы, только на недавнем Ubuntu
что-то изменилось в последнее время, я думаю.
GnuCOBOL полагается на динамическую компоновку, символы просматриваются с dlsym во время выполнения. Этот код поддержки во время выполнения вызова находится в OpenCOBOL уже около 7 лет. Он больше не работает на Ubuntu 14.04, но работает под Fedora 19/20.
ldd больше не показывает библиотеки, перечисленные с помощью -l
например, в качестве теста, Ubuntu 14.04.1
следующая программа COBOL
identification division.
program-id. simple.
procedure division.
call "gtk_init" using
by value 0
by reference null
returning omitted
end-call
goback.
end program simple.
$ cobc -x -v -lgtk-3 simple.cob
preprocessing simple.cob into /tmp/cob710_0.cob
parsing /tmp/cob710_0.cob (simple.cob)
Return status: 0
translating /tmp/cob710_0.cob into /tmp/cob710_0.c (simple.cob)
gcc -pipe -c -I/usr/local/include -Wno-unused -fsigned-char -Wno-pointer-sign -o "/tmp/cob710_0.o" "/tmp/cob710_0.c"
gcc -pipe -Wl,--export-dynamic -o simple /tmp/cob710_0.o -L/usr/local/lib -lcob -lm -lgmp -lncurses -ldb -ldl -l"gtk-3"
в двоичной Нет указаний на то, что libgtk-3.как и в миксе.
./simple
libcob: Cannot find module 'gtk_init'
$ ldd simple
linux-vdso.so.1 => (0x00007fff2c9fe000)
libcob.so.1 => /usr/local/lib/libcob.so.1 (0x00007f2549b06000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2549740000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2549439000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f25491c5000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f2548fa2000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f2548d78000)
libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f25489d6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f25487d2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2549d56000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f25485b3000)
а затем на Fedora 20, та же версия компилятора (построенная немного по - другому, поиск ncursesw вместо ncurses-предполагая, что это не является частью проблемы)
$ cobc -x -v -lgtk-3 simple.cob
Command line: cobc -x -v -lgtk-3 simple.cob
Preprocessing: simple.cob -> /tmp/cob20658_0.cob
Return status: 0
Parsing: /tmp/cob20658_0.cob (simple.cob)
Return status: 0
Translating: /tmp/cob20658_0.cob -> /tmp/cob20658_0.c (simple.cob)
Executing: gcc -std=gnu99 -c -I/usr/local/include -pipe -Wno-unused
-fsigned-char -Wno-pointer-sign -o "/tmp/cob20658_0.o"
"/tmp/cob20658_0.c"
Return status: 0
Executing: gcc -std=gnu99 -Wl,--export-dynamic -o "simple"
"/tmp/cob20658_0.o" -L/usr/local/lib -lcob -lm -lgmp
-lncursesw -ldb -ldl -l"gtk-3"
Return status: 0
$ ldd simple
linux-vdso.so.1 => (0x00007fffae9cf000)
libcob.so.4 => /usr/local/lib/libcob.so.4 (0x00007f4ff2548000)
libm.so.6 => /lib64/libm.so.6 (0x0000003e5ae00000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x0000003e7a200000)
libncursesw.so.5 => /lib64/libncursesw.so.5 (0x0000003e5d200000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003e69800000)
libdb-5.3.so => /lib64/libdb-5.3.so (0x0000003e6ac00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003e5b200000)
libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x0000003e6ba00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003e5aa00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e5b600000)
/lib64/ld-linux-x86-64.so.2 (0x0000003e5a600000)
libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x0000003e6a800000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003e65600000)
libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x0000003e75200000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f4ff2206000)
libXi.so.6 => /lib64/libXi.so.6 (0x0000003e62600000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x0000003e5fe00000)
libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x0000003e6a400000)
libcairo.so.2 => /lib64/libcairo.so.2 (0x0000003e71000000)
libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x0000003e6e000000)
libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x0000003e75600000)
libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x0000003e6c600000)
libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x0000003e71c00000)
libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x0000003e73600000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x0000003e61600000)
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x0000003e66600000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003e5fa00000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003e5e600000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x0000003e61e00000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x0000003e62200000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x0000003e62e00000)
libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x0000003e74e00000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x0000003e67e00000)
libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x0000003e6ec00000)
libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x0000003e6b000000)
libwayland-cursor.so.0 => /lib64/libwayland-cursor.so.0 (0x0000003e69c00000)
libXext.so.6 => /lib64/libXext.so.6 (0x0000003e5ea00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003e5ce00000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003e61a00000)
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x0000003e6f000000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x0000003e60e00000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003e5da00000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x0000003e6f800000)
libEGL.so.1 => /lib64/libEGL.so.1 (0x0000003e73200000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x0000003e5f600000)
libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x0000003e6e800000)
libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x0000003e70800000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x0000003e61200000)
libz.so.1 => /lib64/libz.so.1 (0x0000003e5ba00000)
libGL.so.1 => /lib64/libGL.so.1 (0x0000003e68200000)
libatspi.so.0 => /lib64/libatspi.so.0 (0x0000003e6c200000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x0000003e62a00000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003e60a00000)
libffi.so.6 => /lib64/libffi.so.6 (0x0000003e5ee00000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003e5ca00000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003e5e200000)
libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x0000003e6fc00000)
libXau.so.6 => /lib64/libXau.so.6 (0x0000003e5d600000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x0000003e65e00000)
libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x0000003e67200000)
libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x0000003e70400000)
libxcb-shape.so.0 => /lib64/libxcb-shape.so.0 (0x0000003e72a00000)
libgbm.so.1 => /lib64/libgbm.so.1 (0x0000003e70c00000)
libudev.so.1 => /lib64/libudev.so.1 (0x0000003e63200000)
libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x0000003e74a00000)
libglapi.so.0 => /lib64/libglapi.so.0 (0x0000003e67600000)
libdrm.so.2 => /lib64/libdrm.so.2 (0x0000003e67a00000)
libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x0000003e66e00000)
libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x0000003e66200000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003e5c600000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x0000003e5c200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e5be00000)
сгенерированный код C (GnuCOBOL использует C-промежуточные) на Ubuntu
/* Line: 4 : CALL : simple.cob */
cob_procedure_params[0] = (cob_field *)&c_1;
cob_procedure_params[1] = NULL;
cob_glob_ptr->cob_call_params = 2;
if (unlikely(call_gtk_init.funcvoid == NULL)) {
call_gtk_init.funcvoid = cob_resolve_cobol ("gtk_init", 0, 1);
}
call_gtk_init.funcnull ((cob_s32_t)0LL, NULL);
b_1 = 0;
И Fedora
/* Line: 4 : CALL : simple.cob */
cob_procedure_params[0] = (cob_field *)&c_1;
cob_procedure_params[1] = NULL;
cob_glob_ptr->cob_call_params = 2;
if (unlikely(call_gtk_init.funcvoid == NULL)) {
call_gtk_init.funcvoid = cob_resolve_cobol ("gtk_init", 0, 1);
}
call_gtk_init.funcnull ((cob_s32_t)0LL, NULL);
b_1 = 0;
Я получаю хорошие результаты на Ubuntu (полные подсказки связи ELF), когда gtk_init вызывается из C, а не как строка передано в cob_resolve. Протестировано с помощью gcc-o simple simple-gtk.c-lgtk-3
Итак, что изменилось с предположениями, окружающими-llibname? Похоже, что он не включен в данные ELF для dlopen, чтобы даже пытаться искать libgtk-3.так что
дополнительная информация: ошибочные строки компиляции на Ubuntu действительно заставляют выглядеть так, как будто это должно работать. (С ошибкой gtk)
$ cobc -x -v -lgkt-3 simple.cob
Command line: cobc -x -v -lgkt-3 simple.cob
Preprocessing: simple.cob -> /tmp/cob13556_0.cob
Return status: 0
Parsing: /tmp/cob13556_0.cob (simple.cob)
Return status: 0
Translating: /tmp/cob13556_0.cob -> /tmp/cob13556_0.c (simple.cob)
Executing: gcc -std=gnu99 -c -I/usr/local/include -pipe -Wno-unused
-fsigned-char -Wno-pointer-sign -o "/tmp/cob13556_0.o"
"/tmp/cob13556_0.c"
Return status: 0
Executing: gcc -std=gnu99 -Wl,--export-dynamic -o "simple"
"/tmp/cob13556_0.o" -L/usr/local/lib -lcob -lm -lgmp -lncurses
-ldb -ldl -l"gkt-3"
/usr/bin/ld: cannot find -lgkt-3
collect2: error: ld returned 1 exit status
Return status: 256
и все же, с правильной строкой компиляции, эльф не показывает никаких намеков на связь с gtk-3
Я уже некоторое время царапаю голову на этом. Ищу подсказку о том, какие предположения изменились с Ubuntu и gcc и/или LD и / или dlopen dlsym.
пакет open-cobol работает в репозиториях Debian и Ubuntu уже несколько лет. Даже более старые версии GnuCOBOL (GNU Cobol и OpenCOBOL)на Ubuntu все терпят неудачу. Что-то изменилось и мы не получили памятки. Более чем готовы изменить источники компилятора, но сначала ищите дружественные идеи StackOverflow.
это, похоже, не проблема локальной среды, так как эта проблема Ubuntu появляется и для других. Это также похоже на один из тех DOH! просто исправить проблемы.
более чем готовы добавить больше журналов компиляции, LD_DEBUG=все дампы или straces и т. д.
2 ответов
это похоже на изменение драйвера компилятора для ubuntu-это добавление --as-needed опция для строки компиляции при отправке кода в collect2 он же линкер.
чтобы понять, что происходит, нам нужно разобрать выполнение cobc больше, чем показано:
cobc -x -v simple.cob -lgtk-3
preprocessing simple.cob into /tmp/cob2743_0.cob
translating /tmp/cob2743_0.cob into /tmp/cob2743_0.c
gcc -pipe -c -Wno-unused -fsigned-char -Wno-pointer-sign -o /tmp/cob2743_0.o /tmp/cob2743_0.c
gcc -pipe -Wl,--export-dynamic -o simple /tmp/cob2743_0.o -L/usr/lib -lcob -lm -lgmp -lncurses -ldb -ldl -lgtk-3
если мы разобьем его на код производства C, а затем скомпилируем его, мы получим:
cobc -C -x -v simple.cob
gcc -pipe -c -Wno-unused -fsigned-char -Wno-pointer-sign -o simple.o simple.c
gcc -pipe -Wl,--export-dynamic -o simple simple.o -L/usr/lib -lcob -lm -lgmp -lncurses -ldb -ldl -lgtk-3
нам нужно дополнительно разобрать последнюю строку gcc в:
gcc -### -pipe -Wl,--export-dynamic -o simple simple.o -L/usr/lib -lcob -lm -lgmp -lncurses -ldb -ldl -lgtk-3
, который дает в качестве вывода:
/usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 "--sysroot=/" --build-id --eh-frame-hdr -m elf_x86_64 "--hash-style=gnu" --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o simple /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. --export-dynamic simple.o -lcob -lm -lgmp -lncurses -ldb -ldl -lgtk-3 -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
проблема заключается в наличии первый --as-needed option-он опрокидывает все явные -l параметры в командной строке-если в .o, которые составляют файл, который зависит от библиотеки, он не будет связывать библиотеку в - это точный динамический случай загрузки.
это, кажется,иметь дело с Онейроидное.
этот самый простой обходной путь добавляет:
COB_LDFLAGS=-Wl,--no-as-needed
в вашу среду, которая должна устранить проблему связывания.
из вывода следует, что код C, который динамически ищет gtk_init не знает о загрузке фактический libgtk-3.so общий объект во время выполнения.
вы можете скомпилировать с cobc, используя . Это вызовет ваши библиотечные функции, такие как gtk_init напрямую, а не через вызовы dlopen/dlsym . Более подробную информацию об этой опции можно найти на страницах info с помощью команды info opencobol:
с параметрами компилятора - fstatic-call, более эффективный код будет генерируется следующим образом:
subr(X);обратите внимание, что эта опция действует только тогда, когда вызывается имя программы является буквальным (например,
CALL "subr".'). With a data name (likeзвоните СУБР.'), программа по-прежнему называется динамически.
если вы хотите пройти динамический маршрут, я могу только предложить сообщить вашему приложению Cobol, какие именно динамические объекты вы хотите загрузить во время выполнения. Для этого можно задать переменную среды COB_PRE_LOAD перед запуском приложения. Информацию об этой переменной среды можно найти в этом открытом Cobol документация. В частности, он говорит:
COB_PRE_LOAD - это переменная среды, которая управляет тем, какие модули динамической связи включены в прогон.
$ cobc occurl.c
$ cobc occgi.c
$ cobc -x myprog.cob
$ export COB_PRE_LOAD=occurl:occgi
$ ./myprog
это позволит распознавателю ссылок среды выполнения OpenCOBOL найти точку входа для вызова "CBL_OC_CURL_INIT" в occurl.Итак, модуль. Примечание: модули, перечисленные в переменной окружения COB_PRE_LOAD не имеют расширения. OpenCOBOL будет делать правильные вещи на различных платформах.
вы можете сделать это несколькими способами (используя bash):
COB_PRE_LOAD=libgtk-3 ./simple
это COB_PRE_LOAD использовать libgtk-3.so (вы оставляете .so) запустите приложение, и когда закончите сброс COB_PRE_LOAD вернемся к тому, что было. Вы также можете использовать export для установки переменной окружения на время вашего сеанса с:
export COB_PRE_LOAD=libgtk-3
./simple
вы можете указать несколько общих объектов, используя COB_PRE_LOAD, разделяя их двоеточием. Так что, если вам нужно libgtk-3 и libgmp например, вы можете сделать следующее:
COB_PRE_LOAD=libgtk-3:libgmp ./simple