Linux.by

делаю так:

ln -s -f `g++ -print-file-name=libstdc++.a`

STDLIBS=$(STDLIB_PATH)/libpthread.so\
$(STDLIB_PATH)/libdl.so

LINK32=g++
LINK32_FLAGS=-L. -static-libgcc
LINK32_OBJS=object_files.o

exe_file: $(LINK32_OBJS)
$(LINK32) -o $@ $(LINK32_FLAGS) $(LINK32_OBJS) $(STDLIBS)

rm -f libstdc++.a

Что тут не так - все компиляется, но когда делаю это:
ldd exe_file - прлучаю вот такое:
libpthread.so.0 => /lib/libpthread.so.0 (0x402be000)
libdl.so.2 => /lib/libdl.so.2 (0x40311000)
libm.so.6 => /lib/libm.so.6 (0x40314000)
libc.so.6 => /lib/libc.so.6 (0x40336000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4046f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40522000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


Dct hfdyj tcnm libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4046f000)!!!!!

Не зна. - но может быть проблема была в следующем:

Мое приложение прльзовало староннюю динамическую библиотеку (xerces.so), которая в свою очередь при линковке тянула за собой libstdc++.so.5. Как только я перекомпилял xerces.so в xerces.а, те сделал static lib, то у меня все красиво скомпилялось- естественно вырос размер exe, но теперь уже ldd показывает, что libstdc++.so.5 не нужна...

Сам спросил - сам ответил, хотя родился другой вопрос:

действительно-ли при линковке *.so хочет другую *.so, и ни как не скомпиляется с *.a??

если ваше приложение работает по сети - то переносе на машину с более другим libc со своей статической линковкой можете поймать массу проблем.

mend0za писал(а):если ваше приложение работает по сети - то переносе на машину с более другим libc со своей статической линковкой можете поймать массу проблем.

я чего-то не понимаю наверное, но я статически компильнул libgcc для того что бы не было проблем при переноси exe на другой PC!!??
В частности были проблемы с gethostbyname. При переноси с RH9 на RHE4 было вроде SIGFAULT...

LINK32_FLAGS=-L. -static-libgcc -static может?

объясню по порядку:

залинковали вы libstdc++ и libc статически

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

и всё равно будут проблемы

так что универсального способа нет

только собрать под обе системы отдельные бинарники

в общем я сделал так: нашел *.so которая при линковке тянула за собой libstdc++.so.5, хотя я и указал что libstdc++.so.5 надо компилять как static. Затем эту *.so заменил на *.a и она уже не тянет за собой libstdc++.so.5! Работает и на rh9 (2.4) и на rhe4 (2.6).

пока ни каких проблем с этим не было...

проблемы могут возникнуть на разрешении имён (DNS)

mend0za писал(а):проблемы могут возникнуть на разрешении имён (DNS)

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

я говорю о проблемах при запуске, а не при компиляции


вопрос получения двух бинарников для разных систем в linux решается просто - делается chroot-каталог для целевой системы (то есть копия файлов с неё в подкаталог другой, либо с чистой инсталяции такой-же операционки)

далее - компиляция в chroot (см man chroot)