undefined reference in shared library

Во-первых давай полный вывод ошибки, во-вторых давай вывод ld твоя-нелинкующаяся библиотека.

Сборка библиотеки:

karak@u32:~/shlibtest/shlib$ make
g++ -O2 -fPIC -I. -I.. -c -MD libfile.cpp
g++ -shared -Wl,-soname,libtest.so.0 -o libtest.so.0.0 libfile.o -ldl -lrt -lc
chmod 666 libtest.so.0.0
ln -sf /home/karak/shlibtest/shlib/libtest.so.0.0 /home/karak/shlibtest/shlib/libtest.so.0
ln -sf /home/karak/shlibtest/shlib/libtest.so.0 /home/karak/shlibtest/shlib/libtest.so

Сборка приложения:

karak@u32:~/shlibtest/test$ make
g++ -g -Wall -c -MD test.cpp
g++ -Wl,-rpath,/home/karak/shlibtest/shlib -L"/home/karak/shlibtest/shlib" -ltest test.o -o test
test.o: In function `main':
/home/karak/shlibtest/test/test.cpp:23: undefined reference to `lib_fprintf'
collect2: ld returned 1 exit status
make: *** [test] Error 1

Тестовая библиотека с одной функцией:

#include <stdio.h>
extern «C» {
void lib_fprintf(void)
{
fprintf(stderr, «%s, %d: %s(): Hello World!\n», __FILE__, __LINE__, __FUNCTION__);
}
}

Тестовое приложение с одной функцией:

#include <stdio.h>
#include <stdlib.h>

extern «C» void lib_fprintf(void);

int<--->main( int argc, char *argv[] )
{
lib_fprintf();
return 0;
}

>-ltest test.o -o test

...

А вообще, юзай автотулзы и либтул :}

Cmake тогда уж. Зачем всякое говно мамонта человеку предлагаешь.

Так если макросы раскрыть то вроде так и получается? Или я чего то не понял?

Ниасилил. Порядок линковки только для статических библиотек важен.

В любом случае, где .la-файлик то?

Это если libtool использовать, а здесь должно собираться без него. Я перечитал еще раз про *.so библиотеки там такого файла нет.

Вот здесь лежит код.

http://narod.ru/disk/30539921001/shlibtest.tar.gz.html

Хм, странно. В общем, у меня всё работает

/tmp/pewpew/lib $ make
g++ -O2 -fPIC -I. -I.. -c -MD lib.cpp
g++ -shared -Wl,-soname,libtest.so.0 -o libtest.so.0.0 lib.o -ldl -lrt -lc
chmod 666 libtest.so.0.0
ln -sf /tmp/pewpew/lib/libtest.so.0.0 /tmp/pewpew/lib/libtest.so.0
ln -sf /tmp/pewpew/lib/libtest.so.0 /tmp/pewpew/lib/libtest.so
/tmp/pewpew/lib $ ls
Makefile  lib.cpp  lib.d  lib.o  libtest.so  libtest.so.0  libtest.so.0.0
/tmp/pewpew/lib $ cd ..
/tmp/pewpew $ ls
app  lib
/tmp/pewpew $ cd app/
/tmp/pewpew/app $ make
g++ -g -Wall -c -MD app.cpp
g++ -Wl,-rpath,/tmp/pewpew/lib -L"/tmp/pewpew/lib" -ltest app.o -o test
rm -f *.o *~ core
/tmp/pewpew/app $ ./test 
lib.cpp, 5: lib_fprintf(): Hello World!
/tmp/pewpew/app $ uname -a
Linux ion 3.0.0-1-686-pae #1 SMP Wed Aug 17 04:28:34 UTC 2011 i686 GNU/Linux
/tmp/pewpew/app $ 

А gcc --version что выдает? Кстати на чистой системе Ubuntu 11.10 установленной с диска, а не через обновление - тот же эффект.

gcc (Debian 4.6.1-11) 4.6.1

Попробуй сделать для начала всё руками, без makefile'ов, шаманств со страшными ключами типа -soname и создания ссылок. Просто и тупо:

g++ -shared libtest.cpp -o libtest.so
g++ main.cpp -L. -ltest -o test

Если заработает, то добавляй свои шаманства по одному и смотри где перестанет работать.

-fPIC забыл, без него на x86_64 не заработает

Скорее всего какая-то из функций, используемая в твоих разделяемых библиотеках, в 11.10 переехала в другую системную разделяемую библиотеку. При линковке разделяемой библиотеки линкер не ругается на неопределённые символы, поэтому ты и не получаешь ошибок при линковке. А вот при запуске динамический линкер ругается на неопределённые символы (найденные в твоей разделяемой библиотеке).

У меня почему-то старые файлики в x86_64 компилируются, -fPIC нигде не писал.

Или это cmake добавляет сам?

Потому что ты компилировал из них либо статические либы либы обычные исполняемые файлы. so без -fPIC на x86_64 работать не будет.

ога, а проверить это можно командой ld. только судя по коду, в so'шке всего лишь одна функция, которая использует libc, который и так линкуется по умолчанию.

У меня работает.

Попробуй такие команды для диагностики:

$ nm shlib/libtest.so.0 | grep lib_fprintf
000000000000b208 r _ZZ11lib_fprintfE12__FUNCTION__
0000000000004c10 T lib_fprintf

$ ldd shlib/libtest.so.0
	linux-vdso.so.1 =>  (0x00007fff32bff000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f2829012000)
	librt.so.1 => /lib/librt.so.1 (0x00007f2828e0a000)
	libm.so.6 => /lib/libm.so.6 (0x00007f2828b87000)
	libc.so.6 => /lib/libc.so.6 (0x00007f2828826000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2829453000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f2828610000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f28283f3000)

Вы наверное имеете ввиду ldd, а не ld. Но ldd не показывает неопределённые символы, он показывает только загрузку динамических библиотек (из NEEDED). Вобщем, ldd не поможет найти неопределённые символы, которые не будут определены в рантайме при загрузке всех указанные в NEEDED.

нет, именно ld

Вот вывод этих команд у меня на системе:

karak@u32:~/shlibtest$ nm ./shlib/libtest.so.0 | grep lib_fprintf
0000058a r _ZZ11lib_fprintfE12__FUNCTION__
000004b0 T lib_fprintf
karak@u32:~/shlibtest$ ldd ./shlib/libtest.so.0
linux-gate.so.1 => (0xb7753000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75bc000)
/lib/ld-linux.so.2 (0xb7754000)
karak@u32:~/shlibtest$

При сборке библиотеки и приложения в одном каталоге все собралось. Пища для размышления. Однако.

Сделай таки ld плохая-библиотека.so и напиши вывод сюда (именно ld, а не ldd!). Может там будут unreferenced символы.

При сборке библиотеки и приложения в одном каталоге все собралось. Пища для размышления. Однако.

Методом тыка получается поряд всё таки имеет значение. Вот это:

g++ -Wl,-rpath,/home/alexeys/src/shlibtest/shlib -L"/home/alexeys/src/shlibtest/shlib" -ltest test.o -o test

не работает, а так:

g++ -Wl,-rpath,/home/alexeys/src/shlibtest/shlib -L"/home/alexeys/src/shlibtest/shlib" test.o -o test -ltest

- работает.

Чудо Убунты :)

Посмотрите:

karak@u32:~/shlibtest/shlib$ ld libtest.so ld: warning: cannot find entry symbol _start; not setting start address

Это значит, что всё ok.

Только не убунты, а линковщика. Вообще странно, порядок обычно имел значение только при статической линковки. -ltest точно линкует .so, а не .a ?

Действительно работает. Спасибо :)

Я в общем-то (ооочень давно) брал информацию отсюда:

http://tldp.org/HOWTO/Program-Library-HOWTO/more-examples.html#AEN288

В разделе 3.4

и в 6 примеры.

В примерах действительно указан такой порядок флагов как и использовал abacaba:

gcc -g -o demo_use demo_use.o -L. -lhello

Нужно перечитать еще разок.

Только не убунты, а линковщика. Вообще странно, порядок обычно имел значение только при статической линковки. -ltest точно линкует .so, а не .a ?

Короче, в убунте добавляется флаг --as-needed по-умолчанию к collect2, а в Дебиане по-видимому нет. Если посмотреть, как collect2 запускается и запустить так же без --as-needed - проходит с любым порядком библиотек.