#c #c #linux
#c #c #linux
Вопрос:
У нас есть 32-битное приложение с графическим интерфейсом, созданное с использованием C . Мы перенесли приложение с Solaris на Linux. Проблема, с которой мы сталкиваемся, заключается в
размер библиотеки и исполняемого файла в LINUX очень велик по сравнению с Solaris.
Red Hat Enterprise Linux 5.4 — это версия Linux, которую мы используем.
Пожалуйста, найдите образец созданной динамической библиотеки. Мы хотели бы знать, является ли следующее поведение LINUX нормальным или нет.
Рассмотрим, что мы создали два файла test1.cc и test2.cc . Оба имеют одну строку кода.
a-2720@N530 /data1/users/a-2720/samp :ls -lrt test1.cc test2.cc
-rw-rw-r-- 1 a-2720 mcs 21 May 18 06:16 test1.cc
-rw-rw-r-- 1 a-2720 mcs 21 May 18 06:16 test2.cc
a-2720@N530 /data1/users/a-2720/samp :cat test1.cc
#include<iostream.h>
a-2720@N530 /data1/users/a-2720/samp :cat test2.cc
#include<iostream.h>
Таким образом, файлы содержат только одну строку внутри них
Я создал общую библиотеку, используя эти файлы.
SOLARIS
CC -c -library=iostream -g -mt test1.cc
CC -c -library=iostream -g -mt test2.cc
CC -G -h libtestsolaris.so test1.o test2.o -o libtestsolaris.so -library=iostream
a-2720@N530 /data1/users/a-2720/samp :ls -lrt test1.o test2.o libtestsolaris.so
-rw-rw-r-- 1 a-2720 mcs 20944 May 18 06:16 test1.o
-rw-rw-r-- 1 a-2720 mcs 20944 May 18 06:16 test2.o
-rwxrwxr-x 1 a-2720 mcs 7384 May 18 06:16 libtestsolaris.so
LINUX
CC -m32 -c -library=iostream -g -mt test1.cc
CC -m32 -c -library=iostream -g -mt test2.cc
CC -m32 -G -h libtestlinux.so test1.o test2.o -o libtestlinux.so -library=iostream
/data1/users/adarsh/samp :ls -lrt test1.o test2.o libtestlinux.so
-rw-r--r-- 1 adarsh ifo 20220 May 18 06:44 test1.o
-rw-r--r-- 1 adarsh ifo 20220 May 18 06:44 test2.o
-rwxr-xr-x 1 adarsh ifo 41680 May 18 06:44 libtestlinux.so
Здесь мы можем видеть, что общая библиотека Linux имеет гораздо больший размер, чем solaris когда-то. Пожалуйста, обратите внимание, что исходный файл
для этих библиотек они одинаковы. Наше приложение использует тысячи файлов, имеющих эти заголовочные файлы, и, следовательно, возникает заметная разница в размере.
Мы хотели бы знать, что такая разница в размере является нормальным поведением LINUX.
Сведения о системе
/data1/users/adarsh/samp :cat /etc/*-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
/data1/users/adarsh/samp :uname -a
Linux N280 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Комментарии:
1. Сравните размер
libc(или какой-либо другой библиотеки, общей для ваших систем) между этими двумя. Может дать вам некоторые подсказки.2. Linux и Solaris не являются сокращениями.
3.
iostreamэто большая сложная библиотека с множеством компромиссов в реализации и вариантах компиляции, и различные реализации могут предлагать расширения, влияющие на размер объекта. Такие вещи, как статические таблицы поиска и встраивание, доминируют в ваших результатах. Для более содержательного сравнения используйте все ваше приложение с типичным уровнем оптимизации развертывания после его удаления (форматы отладки отличаются качеством и подробностью) и сосредоточьтесь на резидентном наборе во время реальной работы, а не на размере объекта на диске или виртуальном размере. Какой компилятор вы используете для каждого из них? Комбинации ОС / ЦП (Intel и / или Sparc)?4. Почему проблема с файлом библиотеки размером 40 КБ? Вы уверены, что скомпилировали его без символов отладки и с включенной оптимизацией? В любом случае, 40 КБ действительно крошечные.
Ответ №1:
-g опция добавит отладочную информацию в исполняемый файл, что увеличит его размер. Также включите параметры, которые управляют различными оптимизациями.
Ответ №2:
вы могли бы поиграть с nm, чтобы посмотреть, какой код находится в библиотеке.
Ответ №3:
- не выполнять сборку с использованием символов отладки (опция-g для gcc)
- удалите символы из библиотеки
После выполнения шагов 1 и 2 выполните сравнение.