Реальная МИСТИКА (беда с g++ или с stdc++)

[PAFOS]

Здравствуйте, товарищи кодеры!

Позволю себе небольшое отступление....
Дали мне на дипломную паботу робота Robotino (кому интересно сгуглите, ролики на you tube посмотрите). К нему существует API в виде исходников... но это другая история
на самом роботе (там стоит Debian Linux) есть уже скомпиленное API, я его к себе на комп подтянул через sftp и думал будет мне счастье... а нет...

Теперь к делу...
Само API в компилированном виде содержит три статические либы, librobotinocom.a libxtimer.a libxthread.a. они собраны под i386 архитектуру(проверял через objdump), что совместимо с моей (тож i386).
При сборке Hello world линковщик выдавал кучу неразрешенных внешних ссылок, причем в большинстве своем на std lib плюсов + еще куча других.
Тогда я решил распаковать статическую либу, достав тем самым оттуда объектные файлы, и собрать из них динамическую библиотеку.

В результате имеею librobotinocom.so libxtimer.so libxthread.so

Теперь при сборке проги остались ошибки, относящиеся только к stdc++

Код: Выделить всё

markeshov@markeshov-desktop:~/robotino/my/info$ g++ main.o -o info -L../../lib -lxtimer -lrobotinocom -lxthread -lpthread
../../lib/librobotinocom.so: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned int, std::allocator<char> const&)'
../../lib/librobotinocom.so: undefined reference to `std::basic_streambuf<char, std::char_traits<char> >::_M_out_cur_move(long)'
../../lib/librobotinocom.so: undefined reference to `std::__default_alloc_template<true, 0>::deallocate(void*, unsigned int)'
../../lib/librobotinocom.so: undefined reference to `std::__default_alloc_template<true, 0>::allocate(unsigned int)'
collect2: ld returned 1 exit status

собственно мистика в чем заключается - другие программы с использованием stdc++ нормально компилируются и запускаются!

Я уже почти повесил руки... помоги мне, свежие и светлые головы!

С уважением, Дмитрий

[destr]

Исходники и makefile'ы покажите ну и ссылки на библиотеки

[PAFOS]

да какие Макефайлы, там все в кустарных условиях.. самих cpp нету, одни заголовочные, доки и либы собранные.
API которое валяется на роботе сильно устарело по сравнению с тем, что лежит на svn.openrobotino.org.

[PAFOS]

Хм, мне кажется я понял в чем проблема, однако сам пока не проверил...

Наверное дело в том, что те либы были скомпилены gcc 3.X версией (на роботе именно она), соответственно и libstdc++ тож старая... а я линкую ее с новой, возможно там уже что-то поменялось за столь продолжительный срок

[Atolstoy]

Это часто случается, когда старый код, сделанный под 3-й gcc, не комплится на gcc 4. Выход - правка кода или использование бородатой системы.

[PAFOS]

Блин, жалко в репах убунты нету gcc 3... проверить гипотезу у меня не получится(

[Atolstoy]

Блин, жалко в репах убунты нету gcc 3... проверить гипотезу у меня не получится(

Поставь виртуалку, в ней - старый дистр линукса, в нём скомпиль код.
яйцо в утке, утка в зайце, заяц в шоке

[ormorph]

Хм, мне кажется я понял в чем проблема, однако сам пока не проверил...

Наверное дело в том, что те либы были скомпилены gcc 3.X версией (на роботе именно она), соответственно и libstdc++ тож старая... а я линкую ее с новой, возможно там уже что-то поменялось за столь продолжительный срок

может стоит просто скопировать старые либы с дистрибутива на работе и поставить себе на комп, обычно новые это libstdc++.so.6 а сстарые это libstdc++.so.5
так что старые мешать новым не должны.
ну и виртуальная машина наверное плохое решение(слишком медленно собирается) может стоит использовать тогда LiveCD например KNOPPIX-3.6 он на gcc-3
либо попробовать собрать gcc-3 самостоятельно и установить например в папку /opt и задать переменную PATH когда нужно собрать, под gcc-3.

[Crazy]

Можно взять с репов Debian
http://packages.debian.org/search?keywords=gcc
Написано, что в stable есть.

[PAFOS]

ormorph, не на рабОте, а на рОботе

хотел сделать по простому:

Код: Выделить всё

g++ -V 3.3 ....

что значит запустить g++ соответствующей версии, но прежде ее надо установить)
подтянул пакеты из репов дебиана и тут опять мистика:
есть два пакета
g++-3.3_3.3.6-15_i386.deb и libstdc++5_3.3.6-15_i386.deb

когда ставлю первый система говорит, нельзя мол, этот пакет зависит от второго...
когда ставлю второй пакет, система говорит нельзя, этот пакет зависит от первого... и как прикажите поступить?

а виртуалку ставить или еще че-то качать не охота) тем более, что мне удалось собрать более новое АПИ.. а тему пилю теперь уже только ради проверки гипотезы)

[Atolstoy]

а виртуалку ставить или еще че-то качать не охота)

Но это взаправду удобнее!

[sciko]

Надо ставить их сразу. Например, так

Код: Выделить всё

gdebi g++-3.3_3.3.6-15_i386.deb libstdc++5_3.3.6-15_i386.deb

Либо прикручивать дебиановские репы в source.list .

[PAFOS]

Надо ставить их сразу. Например, так

Код: Выделить всё

gdebi g++-3.3_3.3.6-15_i386.deb libstdc++5_3.3.6-15_i386.deb

Либо прикручивать дебиановские репы в source.list .

я еще тогда догадался сразу, но результат тот же(

короч ладно) не буду мучать себя и вас) наверно все таки гипотезу не мне делать теорией)

[ormorph]

Ну при желании gcc можно самому собрать, версия gcc-3.3.6 нормально собирается из под gcc-4
исходник делается так, сначала собирается просто gcc со статическими ссылками:

Код: Выделить всё

# cd /dir
# tar xjf gcc-3.3.6.tar.bz2
# mkdir build
# cd build
# ../gcc-3.3.6/configure --prefix=/static --enable-languages=c --disable-nls --disable-shared
# make BOOT_LDFLAGS=-static bootstrap
# make prefix=/static install

после этого можно приступить к сборке gcc с динамическими ссылками, при помощи только что собранного компилятора
что то типа этого:

Код: Выделить всё

# rm -rf *
# ./gcc-3.3.6/configure --prefix=/opt/gcc --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
# make CC=/static/bin/gcc bootstrap
# make install

если нужен только g++ то опция задается так languages=c++
остается только добавить в /etc/ld.so.conf строчку:
/opt/gcc/lib
и выполнить от рута команду ldconfig
это для того, чтобы библиотеки были доступны и не надо было создавать сив ссылки в /usr/lib

далее когда надо собрать под gcc-3 то просто выполнить в консоли команду:
export PATH=/opt/gcc/bin:$PATH
после этого можно убедится что g++ видится теперь из /opt/gcc/bin
which g++
Далее как этим инструментом будете пользоваться это уже ваше дело.
проверенно на gcc-4.3.3
желательно более младшие версии gcc чем 3.3.6 не использовать, так как под gcc-4 могут не собраться, зато смогут с помощью вновь собранного компилятора.

вообщем предела извращениям нет

[Crazy]

наверное проще взять apt-get с ключами -m, --ignore-missing

[vda]

Само API в компилированном виде содержит три статические либы, librobotinocom.a libxtimer.a libxthread.a. они собраны под i386 архитектуру(проверял через objdump), что совместимо с моей (тож i386).
При сборке Hello world линковщик выдавал кучу неразрешенных внешних ссылок, причем в большинстве своем на std lib плюсов + еще куча других.

Линковщик искал динамические либы. Дай gcc ключ --static.

Тогда я решил распаковать статическую либу, достав тем самым оттуда объектные файлы, и собрать из них динамическую библиотеку.

Это плохая идея. В лучшем случае полученные динамические либы будут иметь тонны релокаций и не будут разшариваться, в худшем - работать не будут вовсе.

Добейся, чтобы линкер подхватил статик либы, и будет тебе счастие. юзай "g++ -v -Wl,--verbose ..." чтобы увидеть, в какую из не тех степей заходит линкер.

[PAFOS]

Это плохая идея. В лучшем случае полученные динамические либы будут иметь тонны релокаций и не будут разшариваться, в худшем - работать не будут вовсе.

Почему же плохая? статик либа - это ж тупо архивчик объектных... А если объектные компилились с ключем -fPIC тогда и динамическая либа из таких получится неплохая, разве я не прав?