надо скомпилять static libstdc++
надо скомпилять static libstdc++
делаю так:
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)!!!!!
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??
Мое приложение прльзовало староннюю динамическую библиотеку (xerces.so), которая в свою очередь при линковке тянула за собой libstdc++.so.5. Как только я перекомпилял xerces.so в xerces.а, те сделал static lib, то у меня все красиво скомпилялось- естественно вырос размер exe, но теперь уже ldd показывает, что libstdc++.so.5 не нужна...
Сам спросил - сам ответил, хотя родился другой вопрос:
действительно-ли при линковке *.so хочет другую *.so, и ни как не скомпиляется с *.a??
я чего-то не понимаю наверное, но я статически компильнул libgcc для того что бы не было проблем при переноси exe на другой PC!!??mend0za писал(а):если ваше приложение работает по сети - то переносе на машину с более другим libc со своей статической линковкой можете поймать массу проблем.
В частности были проблемы с gethostbyname. При переноси с RH9 на RHE4 было вроде SIGFAULT...
объясню по порядку:
залинковали вы libstdc++ и libc статически
но часть библиотек всё равно подгружается динамически из libc
и всё равно будут проблемы
так что универсального способа нет
только собрать под обе системы отдельные бинарники
залинковали вы libstdc++ и libc статически
но часть библиотек всё равно подгружается динамически из libc
и всё равно будут проблемы
так что универсального способа нет
только собрать под обе системы отдельные бинарники
И увидел я зверя, выходящего из тундры. И число его было 3.14159265358979324...
в общем я сделал так: нашел *.so которая при линковке тянула за собой libstdc++.so.5, хотя я и указал что libstdc++.so.5 надо компилять как static. Затем эту *.so заменил на *.a и она уже не тянет за собой libstdc++.so.5! Работает и на rh9 (2.4) и на rhe4 (2.6).
пока ни каких проблем с этим не было...
пока ни каких проблем с этим не было...
я говорю о проблемах при запуске, а не при компиляции
вопрос получения двух бинарников для разных систем в linux решается просто - делается chroot-каталог для целевой системы (то есть копия файлов с неё в подкаталог другой, либо с чистой инсталяции такой-же операционки)
далее - компиляция в chroot (см man chroot)
вопрос получения двух бинарников для разных систем в linux решается просто - делается chroot-каталог для целевой системы (то есть копия файлов с неё в подкаталог другой, либо с чистой инсталяции такой-же операционки)
далее - компиляция в chroot (см man chroot)
И увидел я зверя, выходящего из тундры. И число его было 3.14159265358979324...